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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
