Re: [ck] [ckpatch][8/29] track_mutexes-1.patch

[Con Kolivas]

On Sunday 18 June 2006 21:28, Juho Saarikko wrote:
> On Sun, 2006-06-18 at 10:31, Con Kolivas wrote:
> > Keep a record of how many mutexes are held by any task. This allows cpu
> > scheduler code to use this information in decision making for tasks that
> > hold contended resources.
>
> So, if I'm an userspace application trying to overcome nice or
> scheduling class limitations, I can simply create a lot of mutexes, lock
> them all, and get better scheduling ?-)
>
> A better way would be to track what task holds what mutex, and when some
> task tries to lock an already locked one, temporarily elevate the task
> holding the mutex to the priority of the highest priority task blocking
> on it (if higher than what the holding task already has, of course).
> Then return the task to normal when it unlocks the mutex.
>
> This might be more trouble and cost more overhead than it's worth, but
> in theory, it would be a supreme system.

No you misunderstand why I use it here. I am not doing priority inheritance at 
all; that comes with all sorts of risks and complexities. This is done purely 
to prevent SCHED_IDLEPRIO tasks from grabbing a mutex and then never getting 
scheduled due to IDLEPRIO semantics while another task is effectively starved 
waiting on that mutex. It is used in -ck only to convert SCHED_IDLEPRIO tasks 
to nice 19 SCHED_NORMAL tasks while they're holding mutexes to do this.

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/