From owner-freebsd-stable@FreeBSD.ORG Thu Oct 4 19:04:20 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEFC416A420 for ; Thu, 4 Oct 2007 19:04:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 3E04513C467 for ; Thu, 4 Oct 2007 19:04:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id l94J2wAg075996; Thu, 4 Oct 2007 21:03:03 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id l94J2rFV075995; Thu, 4 Oct 2007 21:02:53 +0200 (CEST) (envelope-from olli) Date: Thu, 4 Oct 2007 21:02:53 +0200 (CEST) Message-Id: <200710041902.l94J2rFV075995@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, cb@severious.net, matrix@itlegion.ru In-Reply-To: <20071004143944.GA46491@nowhere> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 04 Oct 2007 21:03:03 +0200 (CEST) Cc: Subject: Re: Quation about HZ kernel option X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, cb@severious.net, matrix@itlegion.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 19:04:20 -0000 Craig Boston wrote: > 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. I haven't seen a benchmark yet which would support that. > 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. With HZ=1000 any modern CPU still performs millions of instructions per scheduling quantum. The context switch overhead for the case that a process exceeds its time slice is negligible. > If you're not using polling, you'll > be getting interrupts for network traffic anyway. Right. Probably many more of them than the scheduler switches between processes. > With polling on however, a high HZ value makes sense. Yes, I've seen servers running at HZ=5000 and even more. > > Basically, the kernel cannot handle time slices smaller > > than 1/HZ seconds, for any purpose. > > It should still be able to schedule a new process for the remainder of > the slice should the current one block or yield though, right? Right. And in that case a context switch happens anyway, so reducing the HZ value doesn't buy you anything, except reducing latency for those processes that can do their job quickly (e.g. serving static inline images). I still believe that it's best to not modify the default value of HZ=1000 on such a server. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard." -- Peter van der Linden