Hi Ingo & others....
Just a brief observation on the O(1) scheduler. I'm using 2.4.18-pre7 +
J7 scheduler patch (haven't had a chance to try J9 yet), on a
bog-standard Celeron 500MHz / 384Mb / IDE desktop machine under Red Hat
7.2.
I'm blasting along in Tuxracer (discovery of the week!) and then
"updatedb" kicks in. Tuxracer crawls and jerks for about 15 seconds,
and then turns wonderfully smooth again, whilst the drive continues to
thrash a while longer.
Forgive me if this isn't a relevant scheduler effect, but it struck me
that it might be worth commenting on.
OTOH, using 2.4.17-J6 on a dual Athlon server here, it works great. The
server gets occasionally hammered by fat single-threaded (WINE) jobs,
and the CPU affinity is really working. No more jumping between
processors as it does on stock kernels.
Cheers
Alastair
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Alastair Stevens \ \
MRC Biostatistics Unit \ \___________ 01223 330383
Cambridge UK \___ http://www.mrc-bsu.cam.ac.uk
On Fri, 1 Feb 2002, Alastair Stevens wrote:
> Just a brief observation on the O(1) scheduler. I'm using 2.4.18-pre7
> + J7 scheduler patch (haven't had a chance to try J9 yet), on a
> bog-standard Celeron 500MHz / 384Mb / IDE desktop machine under Red
> Hat 7.2.
>
> I'm blasting along in Tuxracer (discovery of the week!) and then
> "updatedb" kicks in. Tuxracer crawls and jerks for about 15 seconds,
> and then turns wonderfully smooth again, whilst the drive continues to
> thrash a while longer.
well, CPU hogs such as Tuxracer are not as highprio as they used to be.
updatedb has a mixed CPU-intensive and IO-intensive scheduling pattern,
which gives it priority over that of Tuxracer.
One solution would be to start Tuxracer at nice -10, or to renice updatedb
to nice +19.
Ingo