Re: [PATCH RFC] sched: deferred set priority (dprio)

[Mike Galbraith]

On Sat, 2014-08-09 at 01:38 -0700, Sergey Oboguev wrote: 
> On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith <umgwanakikbuti@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/