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

  • From: "jua" <trac@xxxxxxxxxxxx>
  • Date: Tue, 10 Sep 2013 22:33:17 -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):

 Some status update...

 * I created another branch in which I'm experimenting with the RW-lock
 guarding. At first it was not better than an unmodified Haiku, it still
 had the heavy freezing. I suspected classic writer-starvation and wanted
 to see where those writers came from. When I added some tracing-dprintf's
 I learned another thing...

 * ... In my previous comment I wrote that I left the team-port-list locked
 by a regular mutex even in the lockfree-hash branch -- I had assumed that
 accessing it would be rare... oh how wrong I was!

 * Was surprised to find that just moving the mouse cursor causes torrents
 of calls to `set_port_owner()`, constantly changing the ownership of a
 port back and forth between registrar and whatever application is
 responsible for the area below the mouse pointer. I so far know only
 little about app_server/registrar internals, so I just assume that this
 ownership-pingpong is intentional and not a bug?  Anyway,
 `set_port_owner()` is not as lightweight as the function name makes it
 seem, it has to lookup a team ID, lookup a port and then atomically move
 the port from one list to another... and all that protected by a single
 mutex (and in the RW-lock-branch version it always acquired the lock for

 * So another way to handle the team-port-list was needed. Two solutions
 came to mind: a) a separate lock per team as part of the team data
 structure or b) lock striping. I've gone with b) for now and it works well
 enough. Instead of a single mutex guarding all team-port-lists there is
 now an array of 8 mutexes. When code wants to access the list of team `x`
 it has to lock mutex number `(x % 8)`. The choice of '8' is somewhat
 arbitrary, maybe 16 would be better, or maybe not... guess I need to
 benchmark there.

 * With the lock-striping on the team-port-lists, the situation is ''much''
 better for the RW-lock-version. It now has as little freezing as the
 lockfree-hash version -- i.e. the freezing is not totally gone, but much
 better. I've then also integrated the striping into the lock-free branch,
 there it doesn't seem to make much difference though in regards to

 * I've also implemented the ports-by-name hash and using that in the RW-
 lock version for `find_port()` lookups. Doesn't influence the freezing
 though because `find_port()` is rarely called (at least in my current test
 cases). The remaining suggestion about the locking order is still to be
 tried out.

 * I'm curious why there is still a little freezing in both branches. These
 remaining issues are most probably unrelated to the ports list, maybe
 contention on another kernel structure or something else. This is the next
 thing I want to find out about.

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

Other related posts: