From owner-freebsd-performance@FreeBSD.ORG Mon Jun 12 23:16:02 2006 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B5F5516A418; Mon, 12 Jun 2006 23:16:01 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-performance@freebsd.org Date: Tue, 13 Jun 2006 07:15:52 +0800 User-Agent: KMail/1.8.2 References: <20060612195754.72452.qmail@web33306.mail.mud.yahoo.com> <20060612210723.K26068@fledge.watson.org> <20060612203248.GA72885@xor.obsecurity.org> In-Reply-To: <20060612203248.GA72885@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606130715.52425.davidxu@freebsd.org> Cc: danial_thom@yahoo.com, Scott Long , Robert Watson , 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:16:02 -0000 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