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

[Raistlin <raistlin@linux.it>]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

On Tue, 2009-07-14 at 18:31 +0200, Peter Zijlstra wrote:
> > but the discussion since has been entirely about synchronization issues.
> 
> Right, this seems to be a very hot topic.
> 
Indeed! :-D

> Right, Ted holds similar opinions.
> 
> Practically though, active Priority Inheritance has enormous benefits
> for us simple people that need to get things done :-)
> 
> It has allowed us to convert this huge mass of code into something that
> is real-time enough for a lot of practical uses, including industrial
> robots and the like without the need to analyze each and every lock out
> there.
> 
As said to you personally, I put quite a lot of efforts trying to find
some code using PI-futexes directly or PTHREAD_PRIO_INHERIT POSIX
mutexes, for personal curiosity and research interest... But I did not
manage for now. :-(

Do you think it would be possible to have some pointers?

> > In this approach, critical-section lengths must be known, and any
> > lock request that occurs when a task doesn't have sufficient
> > budget is simply denied -- the request is done later when that task
> > receives additional budget.  This avoids a task in one group from
> > holding a lock while it is preempted (which could severely hurt
> > lock-requesting tasks in other groups).  This scheme is really easy
> > to implement in conjunction with the FMLP and it doesn't require
> > complicated budget tracking.  Its effects on blocking terms are
> > also easy to analyze.  Thomas Nolte and colleagues (in Sweden) have
> > written some papers where they've used skip-based locks in
> > hierarchically-scheduled systems.
> 
> Not granting locks when the contender doesn't have enough budget to
> finish them seems like a very attractive solution, however the cost of
> having to analyze the critical section seems prohibitive.
> 
I've always thought so... We have some work related to this as well (can
give pointers if interested), but I personally like PI/BWI-PEP etc.
because such a knowledge is not required at all... Anyway...

> That said, we could maybe experiment with this for a few key lock sites.
> 
... This would be nice!

> Furthermore we're limited by the existing legacy (both spec and code
> wise), but I think we have been able to make good progress through tools
> that help us, such as lockdep and the latency tracer (now ftrace), which
> help us find trouble in an active manner.
> 
Well, in my very humble opinion you're definitely doing great job! :-D

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@ekiga.net /
dario.faggioli@jabber.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]