[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

 * 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: