[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile

  • From: "jua" <trac@xxxxxxxxxxxx>
  • Date: Sun, 08 Sep 2013 15:06:44 -0000

#8007: [app_server] fully unresponsive when resizing window of big textfile
   Reporter:  ttcoder        |      Owner:  axeld
       Type:  bug            |     Status:  new
   Priority:  normal         |  Milestone:  R1
  Component:  System/Kernel  |    Version:  R1/Development
 Resolution:                 |   Keywords:
 Blocked By:                 |   Blocking:  7882, 8136
Has a Patch:  1              |   Platform:  All

Comment (by jua):

 Recently I have found some time to look into this problem again and I have
 a few new findings and a new possible/partial solution.

 As seen from the earlier scheduler recordings, the issue mostly revolves
 around the ports list lock. It's a single mutex which needs to be briefly
 acquired every time a port is read and as such there is an amount of
 contention on it, since all the user interface interaction involves ports
 in one way or another.

 While reading a great book on concurrent programming a while ago, I
 stumbled about its descriptions of lock-free concurrent data structures,
 including a lock-free hash set. Somehow, that made me think about this
 ticket again... wouldn't it be nice to eliminate the ports list lock

 I've gone and implemented that, i.e. changed the ports list to be a lock-
 free hash set. The results are fine: there is no overall system
 performance degradation (not really an increase either, unfortunately) and
 the "freezing"-issues are mostly gone. By "mostly" I mean that when you
 e.g. play a music file in MediaPlayer and then do one of the actions which
 can reproduce the freezing... in the "normal" Haiku version (with ports
 list lock) everything grinds to a halt and the music stops playing
 entirely (seems to be an unrelated MediaPlayer or MediaKit bug, when the
 buffer lateness gets too high, it just freezes and won't even quit
 anymore). With the lock-free patch, there is a short "click" or two in the
 playback, but otherwise it keeps going. Why that still happens is another
 question that needs investigation... but whatever causes it, in the
 patched version it's definitely not the ports list lock! :)

 Then there was another thing I noticed while doing testing and some
 benchmarks of unpatched/patched version (only using the lock-free patch on
 an otherwise unmodified Haiku, used none of the previous prio-inheritance-
 patches attached to this ticket)... on a freshly installed system, I
 couldn't reproduce the heavy freezing problems in an unpatched vanilla
 Haiku. Only the light "maybe a short hiccup"-kind of problem, not the
 heavy one where everything can stop for seconds. That was weird, had the
 problem suddendly solved itself...? Since my main Haiku installation has
 the freezing problems (and is roughly the same hrev as the testing-
 installation), I started to copy configuration files from
 /boot/home/config from the main installation to the testing
 installation... and at some point, I could reproduce the heavy freezing.

 Turns out the heavy freezing is caused by.... Deskbar. Yup, I was
 surprised as well :) To be precise, it is the Deskbar Expander/Auto-
 Expander feature. When the Deskbar is in a screen corner and Auto-Expander
 is on (which is my preferred configuration but not the Haiku default), it
 creates heavy traffic on the ports list mutex, causing the heavy freezing.
 Turn Expanders off (or even just collapse all expanded entries by hand)...
 and the "heavy" freezing is gone and only slight freezing happens. I had a
 brief look at Deskbar sourcecode and the problem comes from the
 "monitor_team_windows()" thread in ExpandoMenuBar.cpp. With expanded
 items, it calls into the app server to get lists of windows and that seems
 to create quite an amount of port list mutex accesses per second.

 As a simple workaround/relief to those who have the problem heavily, I can
 recommend turning off the expanders, that should make it better already.
 Maybe the problem can be solved within Deskbar or app_server... but at
 least as of now I know too little about app_server internals to comment on

 Last but not least I wonder if the lock-free ports list is interesting for
 Haiku regardless. Without Deskbar causing havoc, there is little use for
 it. But if the system should always behave nice even when a program like
 Deskbar does that, it could be good to have. If there is interest I would
 clean up the patch a little and attach it here.

 For reference, here are some scheduler recordings from me, they were made
 when running a little benchmark tool ("FMM" from Splash-2 suite) which is
 capable of producing the "heavy" kind of freezing:

 (1) Vanilla Haiku, Deskbar with Expanders/Auto-Expand enabled
  --> Small waiting time on ports list mutex, only little freezing.
 (2) Vanilla Haiku, Deskbar with Expanders/Auto-Expand disabled:
  --> Heavy traffic on the ports list mutex, heavy freezing.
 (3) Haiku patched for lock-free ports list, Deskbar with Expanders/Auto-
 Expand enabled:
   --> Although Expanders are on, only little freezing, ports list mutex
 doesn't exist anymore.

Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:84>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: