From owner-freebsd-performance@FreeBSD.ORG Mon Jun 12 23:19:59 2006 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BA5216A41F; Mon, 12 Jun 2006 23:19:59 +0000 (UTC) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F3D43D45; Mon, 12 Jun 2006 23:19:54 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.4/8.13.4) with ESMTP id k5CNJqUX043240; Mon, 12 Jun 2006 19:19:52 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.4/8.13.4/Submit) with ESMTP id k5CNJqIb043237; Mon, 12 Jun 2006 19:19:52 -0400 (EDT) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Mon, 12 Jun 2006 19:19:52 -0400 (EDT) From: "Andrew R. Reiter" To: David Xu In-Reply-To: <200606130715.52425.davidxu@freebsd.org> Message-ID: <20060612191828.A38957@fledge.watson.org> References: <20060612195754.72452.qmail@web33306.mail.mud.yahoo.com> <20060612210723.K26068@fledge.watson.org> <20060612203248.GA72885@xor.obsecurity.org> <200606130715.52425.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Robert Watson , freebsd-performance@freebsd.org, danial_thom@yahoo.com, Scott Long , Kris Kennaway Subject: Re: Initial 6.1 questions X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 23:19:59 -0000 On Tue, 13 Jun 2006, David Xu wrote: :On Tuesday 13 June 2006 04:32, Kris Kennaway wrote: :> On Mon, Jun 12, 2006 at 09:08:12PM +0100, Robert Watson wrote: :> > On Mon, 12 Jun 2006, Scott Long wrote: :> > >I run a number of high-load production systems that do a lot of network :> > >and filesystem activity, all with HZ set to 100. It has also been shown :> > >in the past that certain things in the network area where not fixed to :> > >deal with a high HZ value, so it's possible that it's even more :> > >stable/reliable with an HZ value of 100. :> > > :> > >My personal opinion is that HZ should gop back down to 100 in 7-CURRENT :> > >immediately, and only be incremented back up when/if it's proven to be :> > > the right thing to do. And, I say that as someone who (errantly) pushed :> > > for the increase to 1000 several years ago. :> > :> > I think it's probably a good idea to do it sooner rather than later. It :> > may slightly negatively impact some services that rely on frequent timers :> > to do things like retransmit timing and the like. But I haven't done any :> > measurements. :> :> As you know, but for the benefit of the list, restoring HZ=100 is :> often an important performance tweak on SMP systems with many CPUs :> because of all the sched_lock activity from statclock/hardclock, which :> scales with HZ and NCPUS. :> :> Kris : :sched_lock is another big bottleneck, since if you 32 CPUs, in theory :you have 32X context switch speed, but now it still has only 1X speed, :and there are code abusing sched_lock, the M:N bits dynamically inserts :a thread into thread list at context switch time, this is a bug, this :causes thread list in a proc has to be protected by scheduler lock, :and delivering a signal to process has to hold scheduler lock and :find a thread, if the proc has many threads, this will introduce :long scheduler latency, a proc lock is not enough to find a thread, :this is a bug, there are other code abusing scheduler lock which :really can use its own lock. : :David Xu Given that it seems that various scenarios for locking bottlenecks can occur on various systems with different numbers of CPUs. Has there been any research done on providing "best fit" profiles for varied N cpu systems? Cheers, Andrew -- arr@watson.org