#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.