Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: >> some of that back, but not as much as taking them out (even when >> the sysctl'd variable is in a __read_mostly section). We tried a >> patch from Jens to speed up the search for a new partition, but it >> had no effect. > > I find this surprising. The test system has thousands of disks/LUNs which it writes to all the time, in addition to a workload which is a real cache pig. So any increase in the per LUN overhead directly leads to a lot more cache misses in the kernel because it increases the working set there sigificantly. > >> - The RT scheduler changes. They're better for some RT tasks, but not >> the database benchmark workload. Chinang has posted about >> this before, but the thread didn't really go anywhere. >> http://marc.info/?t=122903815000001&r=1&w=2 > > Well. It's more a case that it wasn't taken anywhere. I appear to > have recently been informed that there have never been any > CPU-scheduler-caused regressions. Please persist! Just to clarify: the non RT scheduler has never performed well on this workload (although it seems to get slightly worse too), mostly because of log writer starvation. RT at some point performed significantly better, but then as the RT behaviour was improved to be more fair on MP there were signficant regressions when running under RT. I wouldn't really advocate to make RT less fair again, it would be better to just fix the non RT scheduler to perform reasonably. Unfortunately the thread above which was supposed to do that didn't go anywhere. >> SLUB would have had a huge negative effect if we were using it -- on the >> order of 7% iirc. SLQB is at least performance-neutral with SLAB. > > We really need to unblock that problem somehow. I assume that > enterprise distros are shipping slab? The released ones all do. -Andi -- ak@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
