[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1247601294.4839.137.camel@Palantir>
Date: Tue, 14 Jul 2009 21:54:54 +0200
From: Raistlin <raistlin@...ux.it>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: "James H. Anderson" <anderson@...unc.edu>,
Chris Friesen <cfriesen@...tel.com>,
Douglas Niehaus <niehaus@...c.ku.edu>,
Henrik Austad <henrik@...tad.us>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Bill Huey <billh@...ppy.monkey.org>,
Linux RT <linux-rt-users@...r.kernel.org>,
Fabio Checconi <fabio@...dalf.sssup.it>,
Thomas Gleixner <tglx@...utronix.de>,
Ted Baker <baker@...fsu.edu>,
Dhaval Giani <dhaval.giani@...il.com>,
Noah Watkins <jayhawk@....ucsc.edu>,
KUSP Google Group <kusp@...glegroups.com>,
Tommaso Cucinotta <cucinotta@...up.it>,
Giuseppe Lipari <lipari@...is.sssup.it>,
Bjoern Brandenburg <bbb@...unc.edu>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel
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@...ga.net /
dario.faggioli@...ber.org
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists