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: <1254326306.11233.147.camel@Palantir>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ