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@xxxxxxxxx / dario.faggioli@xxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
