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

From: chris hyser
Date: Fri Feb 21 2020 - 11:51:49 EST

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.