Messages in this thread | | | Date | Fri, 21 Feb 2020 09:29:57 +0000 | From | Qais Yousef <> | Subject | Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints |
| |
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.
> > > > > 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.
Thanks!
-- Qais Yousef
| |