Thread (83 messages) 83 messages, 8 authors, 2021-05-25

Re: [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE

From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Date: 2021-05-20 17:55:35
Also in: linux-arm-kernel, lkml

On 20/05/2021 18:00, Daniel Bristot de Oliveira wrote:
On 5/20/21 5:06 PM, Dietmar Eggemann wrote:
quoted
On 20/05/2021 14:38, Daniel Bristot de Oliveira wrote:
quoted
On 5/20/21 12:33 PM, Quentin Perret wrote:
quoted
On Thursday 20 May 2021 at 11:16:41 (+0100), Will Deacon wrote:
quoted
Ok, thanks for the insight. In which case, I'll go with what we discussed:
require admission control to be disabled for sched_setattr() but allow
execve() to a 32-bit task from a 64-bit deadline task with a warning (this
is probably similar to CPU hotplug?).
Still not sure that we can let execve go through ... It will break AC
all the same, so it should probably fail as well if AC is on IMO
If the cpumask of the 32-bit task is != of the 64-bit task that is executing it,
the admission control needs to be re-executed, and it could fail. So I see this
operation equivalent to sched_setaffinity(). This will likely be true for future
schedulers that will allow arbitrary affinities (AC should run on affinity
change, and could fail).

I would vote with Juri: "I'd go with fail hard if AC is on, let it
pass if AC is off (supposedly the user knows what to do)," (also hope nobody
complains until we add better support for affinity, and use this as a motivation
to get back on this front).

-- Daniel
(1) # chrt -d -T 5000000 -P 16666666 0 ./32bit_app

(2) # ./32bit_app &

    # chrt -d -T 5000000 -P 16666666 -p 0 pid_of(32bit_app)


Wouldn't the behaviour of (1) and (2) be different w/o this patch?

In (1) __sched_setscheduler() happens before execve so it operates on
p->cpus_ptr equal span.

In (2) span != p->cpus_ptr so DL AC will fail.
As far as I got, the case (1) would be spitted in two steps:

 - __sched_setscheduler() will work, then
 - execv() would fail because (span != p->cpus_ptr)

So... at the end, both (1) and (2) would result in a failure...

am I missing something?
Not sure. Reading this thread I was under the assumption that the only
change would be the drop of this patch. But I assume there is also this
'if DL AC is on then let sched_setattr() fail for this 32bit task'.

IMHO, the current patch-stack w/o this patch should let (1) succeed with
DL AC.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help