Messages in this thread | | | Date | Tue, 29 Sep 2009 11:34:29 -0600 | From | "Chris Friesen" <> | 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
| |