* Steven Rostedt <[email protected]> wrote:
> Here we have more unnecessary schedules. So the condition to grab a
> lock should be:
>
> 1. not owned.
> 2. partially owned, and the owner is not RT.
> 3. partially owned but the owner is RT and so is the grabber, and the
> grabber's priority is >= the owner's priority.
there's another approach that could solve this problem: let the
scheduler sort it all out. Esben Nielsen had this suggestion a couple of
months ago - i didnt follow it because i thought that technique would
create too many runnable tasks, but maybe that was a mistake. If we do
the owning of the lock once the wakee hits the CPU we avoid the 'partial
owner' problem, and we have the scheduler sort out priorities and
policies.
but i think i like the 'partial owner' (or rather 'owner pending')
technique a bit better, because it controls concurrency explicitly, and
it would thus e.g. allow another trick: when a new owner 'steals' a lock
from another in-flight task, then we could 'unwakeup' that in-flight
thread which could thus avoid two more context-switches on e.g. SMP
systems: hitting the CPU and immediately blocking on the lock. (But this
is a second-phase optimization which needs some core scheduler magic as
well, i guess i'll be the one to code it up.)
Ingo
-
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]
