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: <200909270855.49367.henrik@austad.us>
Date:	Sun, 27 Sep 2009 08:55:43 +0200
From:	Henrik Austad <henrik@...tad.us>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Raistlin <raistlin@...ux.it>, 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 Tuesday 22. September 2009 20.36.43 Peter Zijlstra wrote:
> On Tue, 2009-09-22 at 14:51 +0200, Raistlin wrote:

>[...]
> > > >  * In case a SCHED_EDF tasks forks, parent's budget is split among
> > > >    parent and child.
> > >
> > > Right, I guess there's really nothing else you can do here...
> >
> > Well, me too... But during tests I run into a poor EDF shell that, after
> > each `ls' or `cat', lost half of its bandwidth up to be no longer
> > capable of running at all! :(
> >
> > We may avoid this having the son giving back its bandwidth to the father
> > when dieing (what a sad story! :( ) but this would need distinguishing
> > between fork-ed and setschedul-ed EDF tasks. Moreover, e.g., what if the
> > son changed its EDF bandwidth in the meanwhile? Or worse if it changed
> > its scheduling policy?
> >
> > At the current time, I'm just splitting the bandwidth, and nothing more.
> > Actually, I also think the solution is the right one, but I would really
> > like to discuss the issues it raises.
>
> Ooh, good point,.. yes we can put some exit hooks in there folding the
> runtime back.
>
> 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.

-- 
     henrik

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)