From owner-freebsd-stable@FreeBSD.ORG Thu Oct 4 19:39:48 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 BFB2916A418 for ; Thu, 4 Oct 2007 19:39:48 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6501C13C481 for ; Thu, 4 Oct 2007 19:39:48 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.13.7) with ESMTP id l94JdiCm022443; Thu, 4 Oct 2007 12:39:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id l94JdiL8022442; Thu, 4 Oct 2007 12:39:44 -0700 (PDT) Date: Thu, 4 Oct 2007 12:39:44 -0700 (PDT) From: Matthew Dillon Message-Id: <200710041939.l94JdiL8022442@apollo.backplane.com> To: "Artem Kuchin" References: <02d401c805cb$abf59ec0$0c00a8c0@Artem><200710041232.l94CWd6W056143@lurza.secnetix.de><20071004143944.GA46491@nowhere><009201c8069d$2f3edc20$0c00a8c0@Artem> <20071004180522.3a724868@epia-2.farid-hajji.net> <200710041852.l94Iq3Db021957@apollo.backplane.com> <007b01c806bb$55c935c0$0c00a8c0@Artem> Cc: freebsd-stable@freebsd.org, cpghost , Craig Boston Subject: Re: Quation about HZ kernel option X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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:39:48 -0000 :Nuts! Everybody has his own opinion on this matter. :Any idea how to actually build syntetic but close to real :benchmark for this? It is literally impossible to write a benchmark to test this, because the effects you are measuring are primarily scheduling effects related to the scheduling algorithm and not so much the time quantum. One can demonstrate that ultra low values of HZ are bad, and ultra high values of HZ are also bad, but everything in the middle is subject to so much 'noise', to the type of test, the scheduler algorithm, and so on and so forth that it is just impossible. This is probably why there is so much argument over the issue. :For example: :Usual web server does: :1) forks :2) reads a bunch of small files from disk for some time :3) forks some cgi scripts :4) dies : :If i write a test in C doing somthing like this and run :very many of then is parallel for, say, 1 hour and then :count how many interation have been done with HZ=100 and :with HZ=1000 will it be a good test for this? : :-- :Regards :Artem Well, the vast majority of web pages are served in a microsecond timeframe and clearly not subject to scheduler quantum because the web server almost immediately blocks. Literally 100 uS or less and the web server's work is done. You can ktrace a web server to see this in action. Serving pages is usually either very fast or the process winds up blocking on I/O (again not subject to the scheduler quantum). CGIs and applets are another story because they tend to be more cpu-intensive, but I would argue that the scheduler algorithm will have a much larger effect on performance and interactivity then the time quantum. You only have so much cpu to play with -- a faster HZ will not give you more, so if your system is cpu bound it all comes down to the scheduler selecting which processes it feels are the most important to run at any given moment. One might think that quickly switching between processes is a good idea but there are plenty of workloads where it can have catastrophic results, such as when a X client is shoving a lot of data to the X server. In that case fast switching is bad because efficient client/server interactions depend very heavily on the client being able to build up a large buffer of operations for the server to execute in bulk. X becomes wildly inefficient with fast switching... It can wind up going 2x, 4x, even 8x slower. Generally speaking, any pipelined workload suffers with fast switching whereas non-pipelined workloads tend to benefit. Operations which can complete in a short period of time anyway (say 10ms) suffer if they are switched out, operations which take longer do not. One of the biggest problems is that applications tend to operate in absolutes (a different absolute depending on the application and the situation), whereas the scheduler has to make decisions based on counting quantums. -Matt Matthew Dillon