Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Aug 2004 12:31:02 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Martin Blapp <mb@imp.ch>
Cc:        freebsd-current@freebsd.org
Subject:   Re: SCHEDULE and high load situations
Message-ID:  <Pine.NEB.3.96L.1040811122806.17560G-100000@fledge.watson.org>
In-Reply-To: <20040811181850.W31181@cvs.imp.ch>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 11 Aug 2004, Martin Blapp wrote:

> > I've found that for throughput oriented workloads, 4BSD substantially
> > outperforms ULE, but I haven't tried it with Jeff's latest set of patches
> > (committed a day or two ago).  You don't mention if your box is SMP, btw
> > -- I've noticed some load balancing problems with ULE previously, but
> > haven't checked if they were resolved.  Anecdotal opinion seems generally
> > to be that interactivity is observably better with ULE than 4BSD, but that
> > 4BSD appears to do a better job under load.
> 
> If the load doesn't grow over 2, I'd say the scheduler is broken. This
> is SMP btw. 

Well, it's a little more complicated than one might think on face value
(not to disagree with your point, though).  The load average is a
statistic measured by the system, based on the notion of a run queue.
Since the run queue is a property of the scheduler, the scheduler is
responsible for coming up with a notion of "load average".  This raises an
interesting question: are we measuring the load average incorrectly on
ULE, are we not getting enough work done, or both.  Given the performance
results seen for throughput on applications like MySQL, which are a direct
property of scheduler operation, I'd say it has a scheduling problem that
might well result in a statistic like the one you're seeing.  However, it
could also be that the statistic is being measured or generated
improperly. 

> > SMP.  Some of the wins on SMP have been from moving to adaptive mutexes by
> > default (most recently, for Giant on i386); others from improved fine
> > grain locking in VM and networking, and general optimization of
> > synchronization primitives, scheduling, wakeups/locking, etc.
> 
> The tests I've done are with your adaptive giant option and Jeff's ULE
> patches. 

You might well want to try 4BSD.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Principal Research Scientist, McAfee Research



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040811122806.17560G-100000>