linux-kernel - Re: [RFC][PATCH] SCHED

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: <4AC24525.9060607@nortel.com>
Date:	Tue, 29 Sep 2009 11:34:29 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Raistlin <raistlin@...ux.it>
CC:	Henrik Austad <henrik@...tad.us>,
	Peter Zijlstra <peterz@...radead.org>, claudio@...dence.eu.com,
	michael@...dence.eu.com, mingo@...e.hu,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	johan.eker@...csson.com, p.faure@...tech.ch,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Subject: Re: [RFC][PATCH] SCHED_EDF scheduling class

On 09/29/2009 10:10 AM, Raistlin wrote:
> On Sun, 2009-09-27 at 08:55 +0200, Henrik Austad wrote:
>>> An alternative is starting the child out with 0 runtime, and have the
>>> parent run sched_setscheduler() on it giving us a clear point to run
>>> admission on.
>>
>> Why not start it as sched_fair/sched_rt and let the child apply for
>> resources the same way the parent did? That would be fairly
>> straightforward and lead to predictable behaviour, and also make a nice, 
>> simple hook into the acceptance-tests.
>>
> Yeah, that's an option as well... It maybe overlap a little bit with
> reset_on_fork, but I like tha fact that it allows the task itself to ask
> for EDF bandwidth without having to rely on its parent... Thoughts about
> that?

Basically it boils down to a policy decision...if a task with guaranteed
cpu allocation fork()s, should the child automatically get a guaranteed
allocation or not?  If so, should that allocation cause the parent's
allocation to be reduced or not?

Personally I don't like the idea of fork() resulting in permanently
reduced allocation for the parent.  I think the logical choices are either

a) The child should get an identical bandwidth guarantee as the parent
and if that can't be guaranteed then the fork() should fail, maybe with
an errno of EBUSY.

b) The child should start out with no guarantees (SCHED_OTHER nice 0
maybe?) and should have to request a bandwidth guarantee.  This could
complicate things in some circumstances because if it can't get the
guarantee then it needs to inform the parent somehow.

Given that any serious users of EDF are likely pretty specialized,
either one would probably work.  Which is the best policy is a different
question, and one that I don't have enough experience with to offer an
opinion.

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