[haiku-development] Proposing kernel patch: mutexes/priorities
- From: Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 01 Mar 2012 17:43:09 +0100
This is a multipart message in MIME format.
Hey!
In relation to bug ticket 8007 [1] I propose a kernel patch (attached
to this mail) which implements:
* Kernel mutex waiting lists sorted by waiter priority (as opposed to
strict FIFO before)
* Priority boosting for kernel mutexes
* For the boosting to work, the thread struct keeps a list of mutexes
held by the thread
The priority boosting works as follows: if a thread A with priority X
holds a mutex and another thread B with priority Y tries to acquire it,
and Y > X, then the priority of A gets temporarily boosted to Y+1. As
soon as A releases the mutex it gets back its old priority X. (except A
still holds more mutexes with higher-priority threads waiting.. then it
gets the priority of the next-highest-priority waiter plus one).
In the discussion of the bugticket, axeld comments that "why should a
low priority thread be able to preempt a high priority thread just
because it acquired a mutex?". While I understand the reasoning, I
think one also has to see the other side: it already happens
implicitly. When a low-priority threads holds a mutex needed by a high-
priority thread it effectively blocks the high-priority thread from
working... it gets scheduled more often, but all it can do is stall and
waste CPU cycles. Even though there is no explicit priority change, it
happens implicitly and causes freezing. So IMO it makes sense to boost
the low-priority thread so it can finish whatever it does quickly and
release the lock again.
This patch does not solve the issues in ticket #8007, only partially.
It does resolve the excessive mutex-wait-times (at least on one of my
systems) seen in the scheduling_recorder output attached to the bug
ticket. However, now the problem is shifted to the second part: waiting
for port read cvar. The system can still freeze for a while with just
StyledEdit, but now it's not due to waiting for mutexes, but waiting
for ports. This needs to be solved as well...
Also, there is still one known problem with the patch: sometimes the
system deadlocks when booting (in the last stage, the rocket icon
already lighted), it always happens in the net_server thread, which got
its priority boosted and then freezes the rest of the boot process. I
have not yet investigated why that is, whether it is a problem in
net_server that just gets uncovered by this patch or if it's a problem
with the functionality of this patch itself. I will look into that.
Would be nice if some Haiku kernel developer could take a closer look
at the patch to see if it's alright. It's the first time I've worked on
something inside the Haiku kernel, I hope I didn't break things :)
Greetings,
Julian
[1] http://dev.haiku-os.org/ticket/8007
Other related posts:
