Date: Wed, 4 Dec 2002 20:08:45 +0100 From: Stijn Hoop <stijn@win.tue.nl> To: Mike Silbersack <silby@silby.com> Cc: hackers@freebsd.org Subject: Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle] Message-ID: <20021204190845.GF52541@pcwin002.win.tue.nl> In-Reply-To: <20021204114915.Q41338-100000@patrocles.silby.com> References: <20021202151816.GJ83264@pcwin002.win.tue.nl> <20021202114019.R31106-100000@patrocles.silby.com> <20021204113154.GA205@pcwin002.win.tue.nl> <20021204114915.Q41338-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--imjhCm/Pyz7Rq5F2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 04, 2002 at 12:01:43PM -0600, Mike Silbersack wrote: > On Wed, 4 Dec 2002, Stijn Hoop wrote: > > With the mentioned change of /etc/sysctl.conf to /boot/loader.conf, I am > > indeed seeing much better times on this 'benchmark'. See attached log. = Not > > only the _select_sleep method benefits from this. What are the reasons = *not* > > to do this? > > > > > As to why Linux may appear "better"... I believe that Linux defaults = to > > > hz=3D100, but that the default switched to hz=3D1000 sometime in the = recent > > > past. > > > > And why don't we do the same? (I suspect this is related to the question > > above :) >=20 > Well, it's generally believed that in the common case (around 100 > processes, and/or with well behaved processes that voluntarily give up > their timeslice) that 100 context switches per second is enough for > smooth performance. Whether this is true or not as you hit 500+ processes > on a busy server is unknown, I don't believe that anyone has done > benchmarking. One argument against more frequent context switches when > you have < 100 processes is that you will be invalidating the contents of > the various caches more often, leading to less efficient overall > performance. The same argument could also be made for the VM system if > the system is under memory pressure. OK, thanks for the explanation. This makes sense. > On the other hand, a higher HZ should create a system which runs a bit > smoother for interactive programs. And, as you point out, it is necessary > for good timing in emulators / simulators / dummynet. Wel, necessary might be an overstatement but seeing as the overhead of the syscalls decreased this much, it would mean a few more frames per second, yes. > In short, I don't think the issue has been discussed much, partially > because it's so easy for those who want hz=3D1000 to just edit loader.con= f. > If you want to propose that we switch to hz=3D1000 by default: Nah, I'll leave that to someone who has some more expertise in writing benchmarks etc. --Stijn --=20 "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc., 1989 --imjhCm/Pyz7Rq5F2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE97lK9Y3r/tLQmfWcRAv9PAKCoUTMcLsStFLi4m5splXIsyXdmfgCgm6Xr vbyco2u3OewLXTWpWo/xQgk= =LFyc -----END PGP SIGNATURE----- --imjhCm/Pyz7Rq5F2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021204190845.GF52541>