Re: RFC for a new Scheduling policy/class in the Linux-kernel

[Raistlin]

On Thu, 2009-07-16 at 09:58 +0200, Peter Zijlstra wrote: 
> > Again, I don't think that either PP or PI is appropriate for use
> > in a (SMP) kernel. For non-blocking locks, the current
> > no-preeemption spinlock mechanism works.  For higher-level
> > (blocking) locks, I'm attracted to Jim Anderson's model of
> > non-preemptable critical sections, combined with FIFO queue
> > service.
> 
But, if I remember well how FMLP works, there is not that much
difference between them two... I mean, if you, at any (kernel|user)
level define a short critical section, this is protected by a
non-preemptive FIFO "queue lock", which is how Linux implements --at
least on x86-- spinlocks! :-O

Also, I'm not sure I can find in the FMLP paper information about the
possibility of a task to suspend itself (e.g., I/O completion) while
holding a short lock... I assume this is not recommended, but may be
wrong, and, in that case, I hope Prof. Anderson and Bjorn will excuse
and correct me. :-)

On the other hand, if with "blocking locks" you intended the long ones,
I think they hare dealt right with suspension and priority inheritance,
even in there.

> Right, so there's two points here I think:
> 
>  A) making most locks preemptible
>  B) adding PI to all preemptible locks
> 
> I think that we can all agree that if you do A, B makes heaps of sense,
> right?
> 
I don't know about all, but I do... I hope I'm not offending anyone
saying that I like priority inheritance!! :-P

> Of course, when the decreased period is still sufficient for the
> application at hand, the non-preemptible case allows for better
> analysis.
> 
Sure! I am impressed as well by the amazing results approaches like the
FMLP give in term of schedulabiulity analysis, and think a little bit of
spinning would not hurt that much, but not to the point of moving all
the locking to spinlocks. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@xxxxxxxxx /
dario.faggioli@xxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part