Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Apr 2004 12:42:09 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Holger Kipp <Holger.Kipp@alogis.com>
Cc:        current@freebsd.org
Subject:   Re: Question: Planned Performance improvements? GIANT free ciss, bge,...?
Message-ID:  <Pine.NEB.3.96L.1040414123649.70783B-100000@fledge.watson.org>
In-Reply-To: <200404140913.i3E9Dpb74482@alogis.com>

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

On Wed, 14 Apr 2004, Holger Kipp wrote:

> I haven't found an overview about the current timeline regarding
> specific devices. As we are going to use a few systems with 5-CURRENT
> for customer production environment (webservers), can anyone comment on
> planned improvements for the next few days/weeks (if any), especially

Kris has already sent you an e-mail pointing out our network locking work,
so I'll just some specifics in your e-mail.  To summarize though -- we
anticipate shipping 5.3 with the network stack running without the Giant
lock, except where specifically required for legacy compatibility (it
looks currently like IPX will require Giant over the entire stack, as well
some older ISA network cards, but I hope to resolve the latter issue).
There are several people working fairly actively to make this happen.

> - GIANT removal for ciss and bge (the others as mentioned by
>   dmesg are npx, acpi, ohci and atkbd).

When run with the netperf patches and appropriate caveats, bge can be run
without Giant.  In fact, in my test environment that's how I use bge.

ciss doesn't yet appear to be ready to run without Giant.

Ohci requires us to address mpsafety throughout the USB stack, and I'm not
sure that's a task that's currently being worked on.

I believe npx's interrupt is a lasting bi-product of x86 hardware using an
off-chip math-coprocessor, and the interrupt was used to wake up the
primary processor when something was needed.  It is not used in today's
hardware, and I believe it largely sits around to reserve the resource for
compatibility reasons.

I'm a little surprised ACPI interrupts require Giant.

> - Other improvements regarding HTT and scheduling? 

Yes, although I'm not sure of the specifics on the scheduling and HTT
fronts.

>   currently, we have 11.3 web pages per second with SCHED_4BSD
>                      11.5 web pages per second with SCHED_ULE
>   with 0% idle under SCHED_4BSD, 5-7% idle under SCHED_ULE.
>   (this is without witness or invariants, of course)
>   (under 4.9-STABLE numbers are slightly below 11)

Especially running with the netperf patch, I've observed a substantial
speedup in kernel-intensive work when running SMP on 5.x vs. 4.x.  I've
noticed some degredation in extremely CPU-intensive userspace work on SMP,
and I'm currently attempting to figure out why that is.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Senior 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.1040414123649.70783B-100000>