Date: Tue, 5 Aug 2003 21:43:51 -0700 From: David Schultz <das@FreeBSD.ORG> To: Roderick van Domburg <r.s.a.vandomburg@student.utwente.nl> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Tuning HZ for semi-realtime applications Message-ID: <20030806044351.GA3881@HAL9000.homeunix.com> In-Reply-To: <3F2F8562.9090609@student.utwente.nl> References: <3F2F8562.9090609@student.utwente.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 05, 2003, Roderick van Domburg wrote: > There's this Linux kernel patch that allows for timeslice tuning. It's > got the following rules of the thumb: > > * The optimal setting is your CPU's speed in MHz's / 2 > * ...but there is no point in going above 1000 Hz > * ...and be sure to use multiples of 100 Hz > > I am everything but an expert at scheduling, but somehow this makes > sense: i.e. one jiffy for the scheduler and one jiffy for the process. > > Does all of this make any sense or is it just a load of hooey? There might be some rationale behind that suggestion, but my first guess would be that someone pulled those numbers out of a hat. In general, doing a context switch has negative cache effects, in addition to the overhead that you pay up front. For optimum throughput, you want to set HZ to the smallest number that still gives acceptable resolution. 100 Hz works just fine for interactive jobs; humans can't tell the difference.[1] For many real-time applications, a higher value is needed. [1] In terms of overhead, I think 100 Hz is well into the noise these days, so bumping that up a little bit would result in negligible difference. I measured 100 vs. 500 a little while ago, and couldn't find a realistic benchmark that was negatively impacted by the higher frequency.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030806044351.GA3881>