Re: [RFC PATCH] sched: START_NICE feature (temporarily nicedforks) (v4)

[Mike Galbraith]

On Tue, 2010-09-21 at 14:01 +0200, Mike Galbraith wrote:

> Since this is mostly about reducing latencies for the non-fork
> competition, maybe a kinder gentler START_DEBIT would work.  Let the
> child inherit parent's vruntime, charge a fraction of the vruntime
> equalizer bill _after_ it execs, until the bill has been paid, or
> whatnot.

One thing that comes to mind is that a lot of this problem is generated,
or rather exacerbated by, sleeper fairness.  For example, take vfork:
parent goes to sleep after passing the baton to the child.  When the
child exits, the parent wakes, gets credit for sleeping while it was
really running in drag, may preempt as a result, and is free to repeat
the procedure, gaining an edge.  START_DEBIT prevents that.

In the naked vfork/exec case, the parent _should_ resume at the relative
vruntime of the child, without further sleeper vruntime adjustment, but
that wouldn't help fix plain fork/clone which can do the same, nor would
it help kbuild's vfork->exec->clone[s]->parallel_stuff->exit unless you
add a lot of complexity... 

(...heh, to end up with something remarkably similar to cgroup container
per process.  Nope, don't want to re-invent the process scheduler to fix
a task scheduler corner case.  That's the core though, same old divide
and conquer problem we've always had.  We have a process scheduler
available these days though.  Back to our task scheduler problem...)

Perhaps take that vslice penalty, apply it to parent and child, and if
present, deduct sleep time from their debt, and only credit sleep time
if there's anything left over?  In any case, seems to me that sleep time
has to be included in the equation while the penalty is in effect.

Guess I'll try that, see what happens.

(but that will likely negate much of the benefit for your testcase,
where parent and child sleep)

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/