Date: Sat, 27 May 2000 17:36:24 +1000 From: "Jacob A. Hart" <c9710216@studentmail.newcastle.edu.au> To: Sheldon Hearn <sheldonh@uunet.co.za> Cc: FreeBSD-CURRENT <freebsd-current@FreeBSD.ORG> Subject: Re: Scheduler changes? Message-ID: <20000527173624.A207@carcass.au.hartware.com> In-Reply-To: <74533.959349665@axl.ops.uunet.co.za>; from sheldonh@uunet.co.za on Fri, May 26, 2000 at 04:01:05PM %2B0200 References: <20000526131949.A9232@carcass.au.hartware.com> <74533.959349665@axl.ops.uunet.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Fri, May 26, 2000 at 04:01:05PM +0200, Sheldon Hearn wrote:
>=20
>=20
> On Fri, 26 May 2000 13:19:49 +1000, "Jacob A. Hart" wrote:
>=20
> > For the past couple of weeks I've noticed rc5des isn't playing friendly=
with
> > the other processes on my system. When running a CPU intensive task (s=
uch
> > as a buildworld, MP3 encoder, or xmame) rc5des hogs around 20-30% CPU e=
ven
> > though, by default, it is niced at +20.
>=20
> As a datapoint, I have a one week old (2000-05-18) CURRENT box that runs
> setiathome all day every day. When builds kick in, setiathome gets
> relagated to the single-digit percentiles in top's display of CPU users.
> This is only true when serious building is happening; those aspects of
> the build that I can imagine are more I/O than CPU intensive give
> setiathome a fighting chance.
Yep. That makes sense.
What puzzles me, though, is the behaviour for processes that aren't I/O
bound.
Here are two top snapshots taken while encoding an MP3 stream directly from
a .wav file on disk. In both cases, the processes were given ample time to
"stabilize" (ie. were left running for about two minutes before the snapshot
was taken).
Kernel from 26th May:
last pid: 23929; load averages: 1.66, 0.85, 0.44 up 1+09:10:34 17:0=
1:31
35 processes: 3 running, 32 sleeping
CPU states: 69.6% user, 28.4% nice, 0.8% system, 1.2% interrupt, 0.0% id=
le
Mem: 65M Active, 33M Inact, 20M Wired, 4480K Cache, 22M Buf, 772K Free
Swap: 256M Total, 256M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
23929 root 79 0 7656K 2024K RUN 0:59 67.56% 66.55% lame
174 root 81 20 952K 436K RUN 320:40 30.27% 30.27% rc5des
Kernel from 29th April:
last pid: 235; load averages: 1.93, 1.02, 0.45 up 0+00:06:00 17:0=
9:10
26 processes: 3 running, 23 sleeping
CPU states: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% id=
le
Mem: 12M Active, 49M Inact, 16M Wired, 12K Cache, 22M Buf, 47M Free
Swap: 256M Total, 256M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
235 root 62 0 7684K 2260K RUN 2:15 98.44% 98.34% lame
174 root 68 20 952K 584K RUN 2:57 0.00% 0.00% rc5des
Check out that rc5des process -- hogging (on average) about 30% CPU in the
first case!
My system feels noticibly sluggish too. The rc5des process interferes with
just about everything (xmame, for example, is unplayable unless I disable i=
t).
I think I'll stick with the April 29th kernel for now ;-)
-jake
--=20
Jacob A. Hart <c9710216@studentmail.newcastle.edu.au>
Powered by: FreeBSD 5.0-CURRENT #4: Sat Apr 29 07:29:02 EST 2000
Loose bits sink chips.
--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: nT11sKAccvEFyYONI76XeKzsU+qB6EU5
iQA/AwUBOS969n1KIGEEZDODEQJbwgCg2KAjymmtVt2YfTkVYh+R/tFqfTUAnjZX
TiJHSLSr7/44yKQ0pD7Bx/Nu
=REqN
-----END PGP SIGNATURE-----
--W/nzBZO5zC0uMSeA--
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?20000527173624.A207>