Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jun 2006 19:19:52 -0400 (EDT)
From:      "Andrew R. Reiter" <arr@watson.org>
To:        David Xu <davidxu@freebsd.org>
Cc:        Robert Watson <rwatson@freebsd.org>, freebsd-performance@freebsd.org, danial_thom@yahoo.com, Scott Long <scottl@samsco.org>, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: Initial 6.1 questions
Message-ID:  <20060612191828.A38957@fledge.watson.org>
In-Reply-To: <200606130715.52425.davidxu@freebsd.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060612191828.A38957>