More ULE bugs fixed.
Jeff Roberson
jroberson at chesapeake.net
Fri Oct 17 01:58:10 PDT 2003
On Fri, 17 Oct 2003, Bruce Evans wrote:
> On Fri, 17 Oct 2003, Jeff Roberson wrote:
>
> > On Fri, 17 Oct 2003, Bruce Evans wrote:
> >
> > > How would one test if it was an improvement on the 4BSD scheduler? It
> > > is not even competitive in my simple tests.
> > > ...
> >
> > At one point ULE was at least as fast as 4BSD and in most cases faster.
> > This is a regression. I'll sort it out soon.
>
> How much faster?
Apache benchmarked at 30% greater throughput due the cpu affinity some
time ago. I haven't done more recent tests with apache. buildworld is
the most degenerate case for per cpu run queues because cpu affinity
doesn't help much and load imbalances hurt a lot. On my machine the
compiler hardly ever wants to run for more than a few slices before doing
a msleep() so it's not bouncing around between CPUs so much with 4BSD.
>
> > > Test 5 for fair scheduling related to niceness:
> > >
> > > for i in -20 -16 -12 -8 -4 0 4 8 12 16 20
> > > do
> > > nice -$i sh -c "while :; do echo -n;done" &
> > > done
> > > time top -o cpu
> > >
> > > With SCHED_ULE, this now hangs the system, but it worked yesterday. Today
> > > it doesn't get as far as running top and it stops the nfs server responding.
>
> > 661 root 112 -20 900K 608K RUN 0:24 27.80% 27.64% sh
> > 662 root 114 -16 900K 608K RUN 0:19 12.43% 12.35% sh
> > 663 root 114 -12 900K 608K RUN 0:15 10.66% 10.60% sh
> > 664 root 114 -8 900K 608K RUN 0:11 9.38% 9.33% sh
> > 665 root 115 -4 900K 608K RUN 0:10 7.91% 7.86% sh
> > 666 root 115 0 900K 608K RUN 0:07 6.83% 6.79% sh
> > 667 root 115 4 900K 608K RUN 0:06 5.01% 4.98% sh
> > 668 root 115 8 900K 608K RUN 0:04 3.83% 3.81% sh
> > 669 root 115 12 900K 608K RUN 0:02 2.21% 2.20% sh
> > 670 root 115 16 900K 608K RUN 0:01 0.93% 0.93% sh
>
> Perhaps the bug only affects SMP. The above is for UP (no CPU column).
>
That is likely, I don't use my SMP machine much anymore. I should setup
some automated tests.
> I see a large difference from the above, at least under SMP: %CPU
> tapers off to 0 at nice 0.
>
> BTW, I just noticed that SCHED_4BSD never really worked for the SMP case.
> sched_clock() is called for each CPU, and for N CPU's this has the same
> effect as calling sched_clock() N times too often for 1 CPU. Calling
> sched_clock() too often was fixed for the UP case in kern_synch.c 1.83
> by introducing a scale factor. The scale factor is fixed so it doesn't
> help for SMP.
Wait.. why are we calling sched_clock() too frequently on UP?
>
> > I think you cvsup'd at a bad time. I fixed a bug that would have caused
> > the system to lock up in this case late last night. On my system it
> > freezes for a few seconds and then returns. I can stop that by turning
> > down the interactivity threshold.
>
> No, I tested with an up to date kernel (sched_ule.c 1.65).
Curious. ULE seems to have suffered from bitrot. These things were all
tested and working when I did my paper for BSDCon. I have largely
neglected FreeBSD since. I can't fix it this weekend, but I'm sure I'll
sort it out next weekend.
Cheers,
Jeff
>
> Bruce
>
More information about the freebsd-current
mailing list