Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints

[chris hyser]

On 2/21/20 5:01 AM, Parth Shah wrote:
> On 2/21/20 2:59 PM, Qais Yousef wrote:
> > On 02/20/20 11:34, chris hyser wrote:
> > > > > Whether called a hint or not, it is a trade-off to reduce latency of select
> > > > > tasks at the expense of the throughput of the other tasks in the the system.
> > > >
> > > > Does it actually affect the throughput of the other tasks? I thought this will
> > > > allow the scheduler to reduce latencies, for instance, when selecting which cpu
> > > > it should land on. I can't see how this could hurt other tasks.
> > >
> > > This is why it is hard to argue about pure abstractions. The primary idea
> > > mentioned so far for how these latencies are reduced is by short cutting the
> > > brute-force search for something idle. If you don't find an idle cpu because
> > > you didn't spend the time to look, then you pre-empted a task, possibly with
> > > a large nice warm cache footprint that was cranking away on throughput. It
> > > is ultimately going to be the usual latency vs throughput trade off. If
> > > latency reduction were "free" we wouldn't need a per task attribute. We
> > > would just do the reduction for all tasks, everywhere, all the time.
> >
> > This could still happen without the latency nice bias. I'm not sure if this
> > falls under DoS; maybe if you end up spawning a lot of task with high latency
> > nice value, then you might end up cramming a lot of tasks on a small subset of
> > CPUs. But then, shouldn't the logic that uses latency_nice try to handle this
> > case anyway since it could be legit?
> >
> > Not sure if this can be used by someone to trigger timing based attacks on
> > another process.
> >
> > I can't fully see the whole security implications, but regardless. I do agree
> > it is prudent to not allow tasks to set their own latency_nice. Mainly because
> > the meaning of this flag will be system dependent and I think Admins are the
> > better ones to decide how to use this flag for the system they're running on.
> > I don't think application writers should be able to tweak their tasks
> > latency_nice value. Not if they can't get the right privilege at least.
>
> AFAICT if latency_nice is really used for scheduler hints to provide
> latency requirements, then the worst that can happen is the user can
> request to have all the created tasks get least latency (which might not
> even be possible). Hence, unless we bias priority or vruntime, I don't see
> the DoS possibility with latency_nice.

A latency nice that does not allow reducing the latency of select tasks at the expense of the throughput of other tasks 
(ie the classic trade-off) doesn't seem to be all that useful and would fail to meet the requirements. Latency nice in 
this view is a directive on how to make that trade-off much like nice is a directive on how to trade-off what should get 
to run next and we don't accept the system optionally treating +19 and -20 tasks the same. Even when we don't get 
exactly what we want we expect "best effort" and that is not the same as optional.

-chrish