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]

Date:	Wed, 30 Sep 2009 17:58:26 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Chris Friesen <cfriesen@...tel.com>
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 Tue, 2009-09-29 at 11:34 -0600, Chris Friesen wrote:
> Basically it boils down to a policy decision...
Yep. I know that, and I know that policies have to be avoided as much as
possible in this lands... :-(

> Personally I don't like the idea of fork() resulting in permanently
> reduced allocation for the parent.  
Yeah, me neither.

> 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.
> 
Again, this could be done, pretty easily actually. :-)

> 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.
> 
Ok, I see and agree, again, to many extents.

> 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.
> 
Yeah... Maybe, since I'm adding (in the next patch I'm going to send
soon) a flag field in the sched_param_ex structure, we can also use some
of the bits for deciding how the fork will behave... The main problem
would be the code will get more complicated, and we thus would have to
decide if it is worth...

Again, thanks for finding some time to comment.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

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