[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)
Comment:
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
measure.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:14>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
