On Thu, Jan 15, 2009 at 03:39:05AM +0100, Andi Kleen wrote: > 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. This particular system has 450 spindles, but they're amalgamated into 30 logical volumes by the hardware or firmware. Linux sees 30 LUNs. Each one, though, has fifteen partitions on it, so that brings us back up to 450 partitions. This system, btw, is a scale model of the full system that would be used to get published results. If I remember correctly, a 1% performance regression on this system is likely to translate to a 2% regression on the full-scale system. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
