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

[chris hyser <chris.hyser@oracle.com>]

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.

Agreed.

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

No problem.

-chrish