Date: Sat, 14 Aug 1999 17:55:56 +0800 From: Peter Wemm <peter@netplex.com.au> To: smp@freebsd.org Subject: simple affinity and pagezero etc. Message-ID: <19990814095556.125FE1C1E@overcee.netplex.com.au>
next in thread | raw e-mail | index | archive | help
As part of the tinkering I've been doing with cpu_switch() etc, I decided
to have another shot at John Dyson's idea of making the idle loop pagezero
stuff into an idleprio kthread/process/whatever.
Anyway, it seems to simplify things a lot, but it's caused a side effect
I hadn't considered..
On this system I run the rc5des client, which rfork()'s into two threads
at nice 19. These effectively block out the process entirely.
On the system with these patches and soft affinity:
last pid: 1380; load averages: 2.94, 2.96, 2.98 up 0+10:14:12 17:39:59
CPU states: 0.4% user, 99.2% nice, 0.0% system, 0.4% interrupt, 0.0% idle
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
1158 peter 105 20 824K 452K RUN 1 60:33 97.95% 97.95% rc564
1157 peter 105 20 824K 452K CPU0 0 60:35 96.92% 96.92% rc564
1380 root 45 0 1560K 764K CPU1 0 0:00 2.31% 0.68% top
4 root 18 52 0K 0K RUN 1 0:03 0.00% 0.00% pgzero
Anyway, the side effect that I hadn't considered was that the pgzero
process sits in the run queue permanently and skews the load average up
by one. ie: the load average is at 3 even though there are two running
processes.
On the other hand, it does simplify things a lot and I'm far more confident
that it's "robust".
I'm tempted to move it from max idprio priority to nice 19 so that it isn't
starved for so long. I suspect it's probably a little better do
occasionally do some pagezeroing if we've left it for a for long enough
for the scheduler to raise it's priority enough to get a shot at the cpu
for a moment.
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990814095556.125FE1C1E>