Date: Thu, 11 Mar 2004 10:37:09 -0500 From: Kenneth Culver <culverk@sweetdreamsracing.biz> To: Ian FREISLICH <if@hetzner.co.za> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: I like SCHED_4BSD Message-ID: <20040311103709.kgcok0c0s0ksooco@www.sweetdreamsracing.biz> In-Reply-To: <E1B1Lh0-0007Rm-00@hetzner.co.za> References: <E1B1Lh0-0007Rm-00@hetzner.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Ian FREISLICH <if@hetzner.co.za>: >> > o Better interactivity -- No mouse jerkiness, no sluggish screen updates = >> when >> > switching between virtual desktops, etc. >> >=20 >> > o Better scheduling! I'm serious here. Watching top under SCHED_ULE, I'm >> > seeing 10, 15, 20 seconds go by where ALL processes are sleeping.=20 >> > Processes seem to be spending inordinate amounts of time in the "kserel" >> > state. This, of course, doesn't happen with SCHED_4BSD. >> >> That this observation may well be bogus, because you're trying to >> measure the scheduler using a tool that is itself run by the >> scheduler, so the process stats you see may not be representative of >> what is really happening on your system. > > That point is taken, however, on my old SMP box _ULE adds an extra > ~5000 seconds of wall clock time to a 'make buildworld -j8' compared > to _BSD 'make world -j8'. > > I did some tests about 3 weeks ago using bind-dlz and postgresql-7.4.1 > on this same machine trying libc_r and libkse using both schedulers. > ULE results with either thread library were dismal ~.33 that of > BSD: ULE gave about 17 authoritive lookups a second with BSD giving > about 50. The KSE library only dropped the rate by about 2 lookups > per second on both schedulers which is essentially noise, but I had > expected an improvement. > > Then there is the question about ULE and processor affinity which > I posed about a week ago which nobody has answered. I'll pose it > here again: > > ------------------------ > I thought I'd give ULE a spin again since according to Robert Watson > and David O'Brien's recents posts it appears that it might not to > slow down my system. > > I noticed this oddity: > > dnetc in order to utilize both CPUs forks a child which also > processes. SCHED_4BSD seems to be aware that the second CPU is > idle and the child or parent (don't really care which) migrates to > the second CPU so that all CPU time is occupied on both CPUs. > > SCHED_ULE doesn't seem to migrate processes to an idle CPU and as > a result one CPU in my system is 100% idle. > > last pid: 677; load averages: 2.06, 1.69, 0.89 up 0+00:09:57 > 09:22:29 > 40 processes: 3 running, 37 sleeping > CPU states: 0.0% user, 50.0% nice, 0.4% system, 0.4% interrupt, 49.2% idle > Mem: 25M Active, 25M Inact, 22M Wired, 56K Cache, 28M Buf, 111M Free > Swap: 512M Total, 512M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND > 624 ianf 139 20 1072K 884K RUN 0 4:00 48.44% 48.44% dnetc > 636 ianf 139 20 1072K 884K CPU0 0 3:26 48.44% 48.44% dnetc > > Do processes have CPU afinity and is that afinity inherited by their > children? Is this a wise thing to do since as demonstrated here > it is possible that all the CPU hogs may land up on 1 processor > thereby pessimising runtime? > ------------------------ > > In my opinion ULE is not yet ready for prime-time. Perhaps it > doesn't affect UP or is even more efficient with UP, but I thought > it was originally tabled as the new scheduler to make the SMP case > more efficient, which it certainly does not. > > Ian > Even on UP, in my totally subjective tests, under a load, 4BSD seems a lot faster. I haven't taken any real measurements of various times for buildworld and all that, but things just "feel" faster with BSD. Ken
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040311103709.kgcok0c0s0ksooco>