I like SCHED_4BSD
Kenneth Culver
culverk at sweetdreamsracing.biz
Thu Mar 11 07:24:49 PST 2004
Quoting Ian FREISLICH <if at hetzner.co.za>:
>> > o Better interactivity -- No mouse jerkiness, no sluggish screen updates =
>> when
>> > switching between virtual desktops, etc.
>> >=20
>> > o Better scheduling! I'm serious here. Watching top under SCHED_ULE, I'm
>> > seeing 10, 15, 20 seconds go by where ALL processes are sleeping.=20
>> > Processes seem to be spending inordinate amounts of time in the "kserel"
>> > state. This, of course, doesn't happen with SCHED_4BSD.
>>
>> That this observation may well be bogus, because you're trying to
>> measure the scheduler using a tool that is itself run by the
>> scheduler, so the process stats you see may not be representative of
>> what is really happening on your system.
>
> That point is taken, however, on my old SMP box _ULE adds an extra
> ~5000 seconds of wall clock time to a 'make buildworld -j8' compared
> to _BSD 'make world -j8'.
>
> I did some tests about 3 weeks ago using bind-dlz and postgresql-7.4.1
> on this same machine trying libc_r and libkse using both schedulers.
> ULE results with either thread library were dismal ~.33 that of
> BSD: ULE gave about 17 authoritive lookups a second with BSD giving
> about 50. The KSE library only dropped the rate by about 2 lookups
> per second on both schedulers which is essentially noise, but I had
> expected an improvement.
>
> Then there is the question about ULE and processor affinity which
> I posed about a week ago which nobody has answered. I'll pose it
> here again:
>
> ------------------------
> I thought I'd give ULE a spin again since according to Robert Watson
> and David O'Brien's recents posts it appears that it might not to
> slow down my system.
>
> I noticed this oddity:
>
> dnetc in order to utilize both CPUs forks a child which also
> processes. SCHED_4BSD seems to be aware that the second CPU is
> idle and the child or parent (don't really care which) migrates to
> the second CPU so that all CPU time is occupied on both CPUs.
>
> SCHED_ULE doesn't seem to migrate processes to an idle CPU and as
> a result one CPU in my system is 100% idle.
>
> last pid: 677; load averages: 2.06, 1.69, 0.89 up 0+00:09:57
> 09:22:29
> 40 processes: 3 running, 37 sleeping
> CPU states: 0.0% user, 50.0% nice, 0.4% system, 0.4% interrupt, 49.2% idle
> Mem: 25M Active, 25M Inact, 22M Wired, 56K Cache, 28M Buf, 111M Free
> Swap: 512M Total, 512M Free
>
> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
> 624 ianf 139 20 1072K 884K RUN 0 4:00 48.44% 48.44% dnetc
> 636 ianf 139 20 1072K 884K CPU0 0 3:26 48.44% 48.44% dnetc
>
> Do processes have CPU afinity and is that afinity inherited by their
> children? Is this a wise thing to do since as demonstrated here
> it is possible that all the CPU hogs may land up on 1 processor
> thereby pessimising runtime?
> ------------------------
>
> In my opinion ULE is not yet ready for prime-time. Perhaps it
> doesn't affect UP or is even more efficient with UP, but I thought
> it was originally tabled as the new scheduler to make the SMP case
> more efficient, which it certainly does not.
>
> Ian
>
Even on UP, in my totally subjective tests, under a load, 4BSD seems a lot
faster. I haven't taken any real measurements of various times for buildworld
and all that, but things just "feel" faster with BSD.
Ken
More information about the freebsd-current
mailing list