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.
-
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]
