[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
entirely?
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
that.
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
http://www.orangejua.de/moo/temp/fmm-expand.sched
--> Small waiting time on ports list mutex, only little freezing.
(2) Vanilla Haiku, Deskbar with Expanders/Auto-Expand disabled:
http://www.orangejua.de/moo/temp/fmm-no-expand.sched
--> Heavy traffic on the ports list mutex, heavy freezing.
(3) Haiku patched for lock-free ports list, Deskbar with Expanders/Auto-
Expand enabled:
http://www.orangejua.de/moo/temp/fmm-lockfree-portslist-expand.sched
--> 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:
