Date: Sat, 8 Mar 2003 18:44:00 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Kris Kennaway <kris@obsecurity.org> Cc: Vallo Kallaste <kalts@estpak.ee>, Jeff Roberson <jroberson@chesapeake.net>, <current@FreeBSD.ORG> Subject: Re: SCHED_ULE ok again. feedback please? Message-ID: <20030308175650.S9565-100000@gamplex.bde.org> In-Reply-To: <20030307165701.GE49729@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Mar 2003, Kris Kennaway wrote:
> On Fri, Mar 07, 2003 at 09:41:07AM +0200, Vallo Kallaste wrote:
> > Althought much better, KDE is still almost unusable, XFree and KDE
> > startup takes a lot more time and starting plain xterm under KDE
> > takes x3 time than usual. When I kill one of the seti processes, all
> > comes down to normal. The one remaining seti process takes 53% of
> > CPU constantly. Don't know how top calculates process CPU usage, but
> > if the 100% is spread over the two processors, then the seti process
> > monopolises one of the processors constantly. Doesn't matter will it
> > run nice 19 or idprio 31.
>
> As noted in Jeff's original mail, niced processes do not behave nicely
> yet.
Niceness is quite broken in -current with the 4bsd scheduler too. It
works a bit better in RELENG_4 since RELENG_4 is missing rev.103 of
proc.h and related changes. I recently started uses my old fixes for
the limited range of {p,kg}_estcpu. In my version, the scaling from
niceness to %CPU is table-driven and has an essentially arbitrary
dynamic range, while the current scaling is built into the algorithm
in an unobvious undocumented way and has a much too small dynamic
range. With my version and a logarithmic relative scaling of
pow(2.0, kg_nice / 4.0), the results of running:
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
top -o cpu
overnight look like this:
%%%
last pid: 2627; load averages: 11.00, 11.00, 11.00 up 0+12:11:21 17:55:21
41 processes: 12 running, 29 sleeping
Mem: 6576K Active, 24M Inact, 26M Wired, 48K Cache, 138M Buf, 191M Free
Swap:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
1439 root 92 -20 800K 556K RUN 265:09 43.99% 43.99% sh
1440 root 95 -16 800K 556K RUN 153:07 26.17% 26.17% sh
1441 root 95 -12 800K 556K RUN 80:30 13.04% 13.04% sh
1442 root 96 -8 800K 556K RUN 40:13 6.01% 6.01% sh
1443 root 96 -4 800K 556K RUN 20:34 2.78% 2.78% sh
1444 root 96 0 800K 556K RUN 9:12 1.03% 1.03% sh
1445 root 96 4 800K 556K RUN 5:50 0.05% 0.05% sh
1446 root 96 8 800K 556K RUN 2:58 0.00% 0.00% sh
1447 root 102 12 800K 556K RUN 1:43 0.00% 0.00% sh
1448 root 105 16 800K 556K RUN 1:00 0.00% 0.00% sh
1449 root 100 20 800K 556K RUN 0:36 0.00% 0.00% sh
297 root 76 0 552K 384K select 0:01 0.00% 0.00% rlogind
726 root 76 0 792K 528K select 0:01 0.00% 0.00% ntpd
261 root 76 0 1932K 1576K select 0:01 0.00% 0.00% sendmail
246 root 4 0 524K 320K nfsd 0:01 0.00% 0.00% nfsd
1 root 8 0 664K 340K wait 0:00 0.00% 0.00% init
299 bde 8 0 1696K 1556K wait 0:00 0.00% 0.00% bash
258 root 76 0 1504K 1004K select 0:00 0.00% 0.00% sshd
%%%
(output produced by non-interactive top).
The dynamic range available to users (from nice -0 to nice -20) is
32:1 in theory (according to the table) and (9:12):(0:36) = 15:1 in
practice (according to top). Theory matches practice better for the
negatively niced processes (28:1)
With -current and SCHED_4BSD, the dynamic range for users is slightly
less than 2:1, which is not good enough for setiathome and similar
processors, so idprio should be used. I think the priority inversion
bugs in idprio are supposed to be fixed in -current, and I have had
no problems using it, but there are still many cases where the kernel
doesn't switch to the highest priority process as soon as possible.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030308175650.S9565-100000>