From owner-freebsd-current@FreeBSD.ORG Thu Mar 11 07:24:49 2004 Return-Path: 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 89CBB16A4CE for ; Thu, 11 Mar 2004 07:24:49 -0800 (PST) Received: from mailhub.sweetdreamsracing.biz (mailhub.sweetdreamsracing.biz [66.92.171.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04ED943D2F for ; Thu, 11 Mar 2004 07:24:49 -0800 (PST) (envelope-from culverk@sweetdreamsracing.biz) Received: by mailhub.sweetdreamsracing.biz (Postfix, from userid 80) id CAF75269; Thu, 11 Mar 2004 10:37:09 -0500 (EST) Received: from 141.156.69.109 ([141.156.69.109]) by www.sweetdreamsracing.biz (Horde) with HTTP for ; Thu, 11 Mar 2004 10:37:09 -0500 Message-ID: <20040311103709.kgcok0c0s0ksooco@www.sweetdreamsracing.biz> Date: Thu, 11 Mar 2004 10:37:09 -0500 From: Kenneth Culver To: Ian FREISLICH References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: I like SCHED_4BSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2004 15:24:49 -0000 Quoting Ian FREISLICH : >> > 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