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

[Mike Galbraith <umgwanakikbuti@gmail.com>]

On Fri, 2014-08-08 at 13:11 -0700, Sergey Oboguev wrote: 
> On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> 
> > task priority cannot be used by any task to describe a critical section.
> > I assert that is that there is _zero_ critical section information present.
> 
> This appears to be the crux of our disagreement.
> 
> This assertion is incorrect. The use of RT to bracket a critical section
> obviously _does_ provide the following information:

You sure don't give up easy.

> 1) designation of entry point for the start of critical activity

Yup, a task can elevate its priority upon entering scram_reactor(), iff
it gets there, scram might still be considered a critical activity.

> 2) designation of exit point, albeit with timing not known in advance at entry
> time

Yeah, exit works ok if enter happens.

You are not going to convince me that it is cool to assign an imaginary
priority to a SCHED_FIFO class task, and still call the resulting mutant
a SCHED_FIFO class task.  Those things have defines semantics.  It is
not ok for a SCHED_FIFO task of a lower priority to completely ignore a
SCHED_FIFO task of a higher priority because it's part of an application
which has one or more wild cards, or maybe even a get out of jail free
card it can pull out of its butt.

NAK.  There it is, my imaginary NAK to imaginary realtime priorities :)

-Mike