[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "jua" <trac@xxxxxxxxxxxx>
- Date: Sat, 14 Sep 2013 13:56:54 -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):
Another little update:
* Searched for the next reason of remaining freezing and it was the port
quota lock, it got acquried as well on every message send and receive. By
reordering the control flow a little and using `atomic_add()` in some
places I could reduce its usage: it now only needs to be locked when new
areas are added to the port message heap.
* Freezing was now even rarer and getting harder to reproduce, but it was
still possible. Found the next obstacle to be the heap's page lock. I
didn't really want to dive into the heap implementation so I wondered
whether there's a way to reduce its usage in general. Added some code to
gather statistics on message sizes. In some general system usage, it
turned out that
* >50% of messages are 1-64 byte in size
* >35% are 65-256 byte.
So if we stop using the heap for messages <= 256 byte, it will affect
80-90% of them. I added some code to use slab object caches for these
cases instead of using the heap allocator. There are two caches: one for
messages 1-64 byte, another for 65-256 byte. Everything larger still uses
the heap.
* With that, I now have a test-version where I can't reproduce freezing at
all anymore. Still could reproduce occasional audio clicking under worst
conditions, but those are when it's waiting on some media-kit-internal
semaphore and not a kernel lock. The mouse cursor always keeps moving
smoothly.
* Next up: further optimization, e.g. the change in locking order. Maybe
it could also be beneficial to not use just one object cache for both
"size classes" (1-64, 65-256), but several, and use them round-robin
(since the object cache has a lock as well, although it doesn't cause
problems in my tests so far).
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:89>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
