Quation about HZ kernel option

[cpghost]

On Thu, 4 Oct 2007 19:42:33 +0400
"Artem Kuchin" <matrix at itlegion.ru> wrote:

> Craig Boston wrote:
> > On Thu, Oct 04, 2007 at 02:32:39PM +0200, Oliver Fromme wrote:
> >> In that case, I would recommend not to override the
> >> default at all (which is 1000).
> > 
> > ISTM that it would be better to use kern.hz=100 in this case.
> > 
> > My reasoning is that a web server shouldn't be terribly sensitive to
> > latency, so it's better to have longer quantums to get more work
> > done without context switching overhead.  If you're not using
> > polling, you'll be getting interrupts for network traffic anyway.
> 
> That what i personally thought. However 100 seems to be too rough.
> I just feel so, no reasoning behind this ;)
> Maybe 200-300 is better than 100 and better than 1000?
> I wonder how to build a test case for this to find best settings for
> web server, so others will not stuggle with this on the future.

Why would 100 Hz be too rough? Up until recently, very big high
traffic web servers were running just fine at 100Hz and some still
do today. As Craig said, it's even better to keep the quantum long,
so that more work can be done. It makes sense to get rid of client
requests as soon as possible, and this is easier done with 100Hz
than with higher clock rates. And since context switching happens
much more frequently than that (at every blocking syscall, including
disk- and network I/O), the server will still be very much
responsive anyway.

AFAICS, polling(4) is the only scenario where a faster clock makes
sense on a web server, and if you absolutely have to do polling,
anything below 800Hz to 1000Hz wouldn't make sense anyway.

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/