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
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.