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

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Mon, 07 Nov 2011 23:26:40 -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:  Servers/app_server  |    Version:  R1/Development
 Resolution:                      |   Keywords:
 Blocked By:                      |   Blocking:
Has a Patch:  0                   |   Platform:  All
Changes (by bonefish):

 * cc: mmlr (added)


 Thanks, Pete! Looking at the analysis a few things are interesting:
  * The "cursor loop" thread, which I believe extracts the mouse events
 from the input server messages and updates the cursor position, shows no
 activity at all between 5.15 s and 6.95 s and only little activity
 afterwards (compared to its activity before 5.15 s). I guess the activity
 depends on the actual mouse movement, so it's hard to say whether the
 activity matches your mouse movement at that time. Its wait behavior looks
 pretty much like one would expect, I suppose: It waited 294 times on the
 "cursor semaphore" for a total of 9.74 s and 4 times on the "floating
 overlays lock" for a total of 0.004 s. So the frozen cursor would either
 point to the event or the drawing side of things.
  * I noticed that there's a total wait time of 1 min 1 s (1159 times) on
 the "ports list" mutex, which is a serious problem. I'm not sure, if I
 messed that up when reworking the kernel locking or if it was already
 broken before. From a quick scan of the ports code one might think that
 locking the port's lock while holding `sPortsLock` (particularly in
 `get_locked_port()` and `set_port_owner()`) could be the reason, but none
 of the port locks actually shows up with a significant amount of wait time
 ("system:roster" with a total of 0.0001 s, four other locks with even
 less). So something else must be the cause. At any rate, I believe the
 enormous contention on the "ports list" lock is the cause for the visual
 freeze, since port messages cannot be sent and threads cannot start
 waiting on a port without first acquiring this lock. And port messaging is
 kind of the backbone of communication with and within the app server.
  * I also noticed that there are 397 waits and a total wait time of 7.44 s
 on the "USB Stack Allocator" mutex. This sounds relatively much for a
 mutex and might be something that should be optimized. CCing mmlr for good

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

Other related posts: