From owner-cvs-src@FreeBSD.ORG Thu Oct 20 15:46:29 2005 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFE6916A41F; Thu, 20 Oct 2005 15:46:29 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5602943D5A; Thu, 20 Oct 2005 15:46:29 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E875846C32; Thu, 20 Oct 2005 11:46:28 -0400 (EDT) Date: Thu, 20 Oct 2005 16:46:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20051020.091925.109166235.imp@bsdimp.com> Message-ID: <20051020164246.O28249@fledge.watson.org> References: <20051020145234.H99720@delplex.bde.org> <200510200958.09182.jhb@freebsd.org> <4357AAFE.2070002@samsco.org> <20051020.091925.109166235.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scottl@samsco.org, src-committers@freebsd.org, jhb@freebsd.org, bde@zeta.org.au, cvs-src@freebsd.org, cvs-all@freebsd.org, davidxu@freebsd.org, gallatin@cs.duke.edu Subject: Re: cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 15:46:29 -0000 On Thu, 20 Oct 2005, M. Warner Losh wrote: > In message: <4357AAFE.2070002@samsco.org> > Scott Long writes: > : However, I'd like to revisit the HZ=1000 decision for 7-CURRENT. > > At Timing Solutions, we run with HZ=1000 to reduce the latency for > interacting with serial devices (since we have highly synchronous > protocols that are spoken over them). Other than that, we've seen no > performance differences between HZ=100 and HZ=1000 in other areas of our > systems. We have noted a small increase in overhead with 1000, but > since we have plenty of CPU to burn, we burn a little to get better > latencies... We'll likely tune the number based on our experience, so > changing the default HZ won't impact us. I've seen reports of TCP improvements as a result of more precise timing, but I've also seen reports of minor performance reduction as a result of the increased overhead. Some of the problems here were reduced by removing naive uses of callouts that ran every tick in order to run their own job scheduler which then selected to run jobs only every now and then. This still exists in some of the RPC-related code in NFS, and needs to be addressed. It's also important for Xen, because in Xen it's desirable to only run per-domain clock ticks if there's work to do, so there are optimizations in Xen to use programmable timers for callouts rather than running them frequently in order to avoid having to run all the domains every time a timer tick fires. Revisiting the 1000hz decision does make sense, but there are real trade-offs here: higher accuracy in timing potentially improves the behavior of retransmission and drop detection for network services in high performance environments. With time scales on packet processing events being on the order of a millionth of a second, things are a lot different than previously. Robert N M Watson