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

From: chris hyser
Date: Fri Feb 21 2020 - 12:09:21 EST

On 2/21/20 4:29 AM, 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

True, but without a bias towards a user at the users request, it's just normal scheduler policy. :-)

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?

One of the experiments I'm planning is basically that; how badly can this be abused by root. Like pretty much everything else, if root wants to destroy the system, not much you can do, but I find it useful to look at the pathological cases as well.

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.


Can you expand on the scenario you have in mind please?

Hopefully, the above helps. It was my original plan to introduce this with a
data laden RFC on the topic, but I felt the need to respond to Parth
immediately. I'm not currently pushing any particular change.


No problem.