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

[Raistlin]

On Mon, 2009-07-13 at 19:28 +0200, Peter Zijlstra wrote:
> > - analyzable from the real-time theorist's point of view... Which is
> >   (un?)fortunately what we are :-)
> > - possible to implement... Which is not always (un!)fortunately obvious 
> >   here :-)
> 
> I would very much like a proper theoretical foundation for whatever we
> end up with ;-)
> 
Well, thus let's hope to manage in it! :-D

> > Very basically: from the analysis point of view one easy and effective
> > solution would be to have the blocked-running tasks --i.e., the tasks
> > blocked on some lock that have been left on the rq to proxy-execute the
> > lock owner-- busy waiting while the lock owner is running. This allows
> > for retaining a lot of nice properties BWI already has, as far as
> > analyzability is concerned.
> 
> Right, practically we cannot do this, since we expose the block graph to
> userspace and you could in userspace construct a program that would
> exploit this spinning to DoS the system.
> 
I know and I share this belief with you, as I wrote in my original
mail... Even if I must say that it would not be a _real_ spinning, such
as raw_spinlock_t, with irq and preemption disabled (like in FMLP), but
only a mean to --preemptively-- consume some budget to avoid
schedulability to be lost!
Thus, I'm not sure it could be the basis for a DoS, especially if tasks
are, individually, as a group or as a whole class, enclosed within
groups (we used to call them reservations as well).

Anyway I'm aware that CPU bandwidth would be wasted, and that this is an
issue in systems like Linux... That's why we are striving for something
better... :-P

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