From owner-freebsd-performance@FreeBSD.ORG Mon Jun 12 23:21:09 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 9CA2016A41B; Mon, 12 Jun 2006 23:21:09 +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 31B8543D49; Mon, 12 Jun 2006 23:21:09 +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 k5CNL8GH043290; Mon, 12 Jun 2006 19:21:08 -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 k5CNL8Jh043287; Mon, 12 Jun 2006 19:21:08 -0400 (EDT) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Mon, 12 Jun 2006 19:21:08 -0400 (EDT) From: "Andrew R. Reiter" To: David Xu In-Reply-To: <20060612191828.A38957@fledge.watson.org> Message-ID: <20060612192015.G38957@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> <20060612191828.A38957@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: danial_thom@yahoo.com, freebsd-performance@freebsd.org, Robert Watson , 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:21:09 -0000 Sorry to reply to myself ... On Mon, 12 Jun 2006, Andrew R. Reiter wrote: :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? Meaning at compile time certain profiles are taken for a given system to provide a good effort at providing a "best fit" for locking with their system. : :Cheers, :Andrew : :-- :arr@watson.org :_______________________________________________ :freebsd-performance@freebsd.org mailing list :http://lists.freebsd.org/mailman/listinfo/freebsd-performance :To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" : : -- arr@watson.org