Message-Id: <bf063130-cd08-2d7b-40eb-84575b4ba271@linux.ibm.com>
Date:   Fri, 21 Feb 2020 15:31:54 +0530
From:   Parth Shah <parth@...ux.ibm.com>
To:     Qais Yousef <qais.yousef@....com>,
        chris hyser <chris.hyser@...cle.com>
Cc:     vincent.guittot@...aro.org, patrick.bellasi@...bug.net,
        valentin.schneider@....com, dhaval.giani@...cle.com,
        dietmar.eggemann@....com, linux-kernel@...r.kernel.org,
        peterz@...radead.org, mingo@...hat.com, pavel@....cz,
        qperret@...rret.net, David.Laight@...LAB.COM, pjt@...gle.com,
        tj@...nel.org
Subject: Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler
 hints



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.

Being conservative for future and considering that only Admin may make
correct decision, I do think to not allow non-root user to give -ve values
for latency_nice.

NICE don't allow reducing the task_nice value even if the value has been
increase by the same user in the past. From my understandings, this don't
make sense much for the latency_nice and user should be free to choose any
value in the range [0,19].


- Parth

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

Powered by blists - more mailing lists