cvs commit: src/sys/kern sched_4bsd.c

David Xu davidxu at freebsd.org
Sun Nov 12 23:17:08 UTC 2006


On Sunday 12 November 2006 14:26, Bruce Evans wrote:
> On Sun, 12 Nov 2006, David Xu wrote:
> > On Sunday 12 November 2006 00:22, Bruce Evans wrote:
> >> On Sat, 11 Nov 2006, David Xu wrote:
> >>> davidxu     2006-11-11 13:11:30 UTC
> >>>
> >>>  FreeBSD src repository
> >>>
> >>>  Modified files:
> >>>    sys/kern             sched_4bsd.c
> >>>  Log:
> >>>  Unbreak userland priority inheriting in NO_KSE case.
> >>
> >> Is this what made the non-KSE case unusable?  At least with the load
> >> average bug fixed, it gave very unfair scheduling, and would only start
> >> about 4 concurrent hog processes on a 2-way SMP system.
> >>
> >> Improvements in some benchmarks may have depended on the bugs.  Maybe
> >> a random load average is optimal for some loads :-).
> >
> > No, this change is unrelated, the bug is in kern_idle.c, John should use
> > mi_switch(), not the choosethread(), otherwise the loadavg is not
> > maintianed correctly.
>
> That's not the bug I meant.  I already had your fix for kern_idle.c.
>
> Testing showed that nothing much is fixed.  Simple benchmarks like:
>
> %%%
> for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> do
>      nice -$i sh -c "while :; do echo -n;done" &
> done
> top -o time
> %%%
>
> and
>
> %%%
> for i in 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> do
>      nice -$i sh -c "while :; do echo -n;done" &
> done
> top -o time
> %%%
>
> still show that scheduling without KSE is very unfair.  They can take
> several minutes to start the `top' process, and "killall sh" can take
> many seconds to start unless you have an rtprio shell to start the
> killall.
>
> With KSE, the top process starts soon enough and shows just the old
> 4BSD scheduler bug that too many cycles are given to niced programs,
> as in all versions of FreeBSD except 4.x.  Since no one uses niced
> programs, this bug is unimportant.
>
> Bruce

It might not be a bug of the NO_KSE, the problem is in sched_fork() and
sched_exit(), for process which quickly fork() a child and then the child
exits quickly, the parent's estcpu will be doubled quickly too, this fairness
is really unfair, I think your examples is the scenario, however, I don't know 
why KSE works better. this might be fixed by remembering the inherited
estcpu in child, and decay it every second. when the child exits, 
it add really used estcpu to parent. code looks like this:

 in sched_fork(), we remember inherited estcpu:
	td->td_inherited_estcpu = parent->td_estcpu;
 in schedcpu(), we decay it every second (should be fixed in sched_wakeup
 too):
        td->td_inherited_estcpu = decaycpu(loadfac, td->td_inherited_cpu);
 in sched_exit();
        parent->td_estcpu = ESTCPULIM(parent->td_estcpu, 
		childtd->td_estcpu - td->td_inherited_cpu);

This should fix the quickly fork() and exit() problem for parent process.

Regards,
David Xu


More information about the cvs-src mailing list