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>