On Fri, 02 Mar 2012 05:43:09 +1300, Julian Harnath <julian.harnath@xxxxxxxxxxxxxx> wrote:
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).
sounds reasonable to me to solve this problem but maybe its even better to temporary reduce the priority of B to X-1? Otherwise you make A the super thread that might block the rest of the system for a very long time? E.g. A could hold the lock forever and thus do everything with the higher priority.
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...
do you know why the port read blocks?Btw, does the scheduler knows if a thread just stalls or has done something? in this case it might be better to vary the priorities in the scheduler, right?
Regards,
Clemens
