From owner-freebsd-current Fri Mar 7 23:45:44 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B21337B401 for ; Fri, 7 Mar 2003 23:45:41 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 077EF43F93 for ; Fri, 7 Mar 2003 23:45:40 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA08081; Sat, 8 Mar 2003 18:44:01 +1100 Date: Sat, 8 Mar 2003 18:44:00 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kris Kennaway Cc: Vallo Kallaste , Jeff Roberson , Subject: Re: SCHED_ULE ok again. feedback please? In-Reply-To: <20030307165701.GE49729@rot13.obsecurity.org> Message-ID: <20030308175650.S9565-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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