linux-kernel - Re: [PATCH v2] Pre-emption control for userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5331F716.30906@oracle.com>
Date:	Tue, 25 Mar 2014 15:37:26 -0600
From:	Khalid Aziz <khalid.aziz@...cle.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	peterz@...radead.org, akpm@...ux-foundation.org,
	andi.kleen@...el.com, rob@...dley.net, viro@...iv.linux.org.uk,
	oleg@...hat.com, gnomes@...rguk.ukuu.org.uk, riel@...hat.com,
	snorcht@...il.com, dhowells@...hat.com, luto@...capital.net,
	daeseok.youn@...il.com, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH v2] Pre-emption control for userspace

On 03/25/2014 02:31 PM, ebiederm@...ssion.com wrote:
>> Yes, it is indeed limited to a cooperating set of userspace
>> tasks/threads. Tasks/threads will explicitly choose to use this feature. It is a
>> no-op for every one else.
>
> It is absolutely not a no-op for me if my task can't be scheduled soon
> enough because your task executed sched-prempt.
>
> It means my latency goes up and the *random bad thing* will happen
> because I missed my deadline because I was not scheduled fast enough.
>

This patch changes only CFS, so SCHED_RR and SCHED_FIFO are not affected 
by this change. Does CFS ever guarantee that any task will be scheduled 
fast enough to meet its critical deadline? Shouldn't a system that 
requires guarantees to meet deadline use SCHED_FIFO or SCHED_RR? Even if 
a task that has an important deadline to meet and is ready to run, it 
can be denied processor time simply based upon which other tasks are 
ready to run, how long they have run previously and what their 
priorities are. I don't see how CFS can guarantee temporal determinism 
other than every task will get a chance to run in a finite time period. 
Please do correct me if my understanding of CFS is flawed.

Any task that asks for extension of its current timeslice will get 
charged this additional time in p->se.vruntime and cause it to move to 
the right on rbtree. This amounts to a task borrowing time from its 
future runtime as opposed to being able to get more processor time than 
others.

>>> or (b) limiting this to just a small
>>> cooperating set of threads in a single cgroup.
>>
>> and that is almost what this patch does. It is not limited to a cgroup, rather
>> to the tasks/threads that ask to use this feature.
>
> Except you do not appear to be considering what could be scheduled in
> your tasks place.
>
> You allow any task to extend it's timeslice.

Would you recommend a policy that determines which tasks are allowed to 
extend their timeslice?

>
> Which means I will get the question why does why does
> really_important_job only miss it's latency guarantees when running on
> the same box as sched_preempt_using_job?

I would expect a system that requires latency guarantees to be designed 
using SCHED_FIFO or SCHED_RR, not SCHED_OTHER.

Hope this makes sense.

Thanks,
Khalid

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/