On Sat, 2014-08-09 at 01:38 -0700, Sergey Oboguev wrote: > On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith <umgwanakikb...@gmail.com> > wrote: > > > I see subversion of a perfectly functional and specified mechanism > > Just wondering if the following line of thinking would sound just as much an > anathema from your perspective or perhaps a bit less terrible... > > Proceeding from the observations (e.g. https://lkml.org/lkml/2014/8/8/492) > that > representative critical section information is not pragmatically expressible > at > development time or dynamically collectable by the application at run time, > the > option still remains to put the weight of managing such information on the > shoulders of the final link in the chain, the system administrator, providing > him with application-specific guidelines and also with monitoring tools. > > It might look approximately like this. > > It might be possible to define the scheduling class or some other kind of > scheduling data entity for the tasks utilizing preemption control. The tasks > belonging to this class and having critical section currently active are > preemptible by RT or DL tasks just like normal threads, however they are > granted a limited and controlled degree of protection against preemption by > normal threads, and also limited ability to urgently preempt normal threads on > a wakeup.
Sure, a completely different scheduling class can implement whatever semantics it wants, just has to be useful and not break the world. (spins lots of complexity) > This is not suggest any particular interface of course, but just a crude > sketch > of a basic approach. I am wondering if you would find it more agreeable within > your perspective than the use of RT priorities, or still fundamentally > disagreeable. Yes, the crux of my objection is the subversion in my view of RT. > (Personally I am not particularly thrilled by the complexity that would have > to be added and managed.) (yeah, you described lots of that) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/