Jens Axboe wrote: > On Wed, May 16 2007, James Bottomley wrote: >> On Wed, 2007-05-16 at 19:53 +0200, Jens Axboe wrote: >>> The 1-page thing isn't a restriction as such, it's just an optimization. >>> The scatterlist allocated is purely a kernel entity, so you could do 4 >>> contig pages and larger ios that way, if higher order allocations were >>> reliable. >>> >>> But you are right in that we need to tweak the sg pool size so that it >>> ends up being a nice size, and not something that either spans a little >>> bit into a second page or doesn't fill a page nicely. On my x86-64 here, >>> a 128 segment sg table is exactly one page (looking at slabinfo). It >>> depends on the allocator whether that is just right, or just a little >>> too much due to management information. >> Actually, if you look at the slab allocation algorithm (particularly >> calculate_slab_order()) you'll find it's not as simplistic as you're >> assuming ... what it actually does is try to allocate > 1 item in n >> pages to reduce the leftovers. > > I'm not assuming anything, I was just being weary of having elements > that are exactly page sized if that would cause a bit of spill into a > second page. Don't tell me that PAGE_SIZE+10 (or whatever it might be) > would ever be an optimal allocation size. > >> Additionally, remember that turning on redzoning, which seems to be >> quite popular nowadays, actually blows out the slab size calculations >> anyway. > > Debugging will always throw these things out the window, we can't and > should not optimize for that. That goes for slab, and for lots of other > things. > >> The bottom line is that it's better for us just to do exactly what we >> need and let the allocation algorithms figure out how to do it >> efficiently rather than trying to second guess them. > > Partly true, it's also silly to just hardcore power-of-2 numbers without > ever bothering to look at what that results in (or even if it fits > normal use patterns). > > We can easily be flexible, so it seems silly not to at least do a bit of > background research. > The thing is that now every thing fits like a glove. i386/32bit-arch have 16 bytes scatterlist struct, 256 in a page. x86_64/64bit-arch 32 byte and 128 fit exactly in a page. If we do any code that throws this off it will be a performance regression. Call it beginners luck, call it someone spent a long night handcrafting it this way. Just that I think the current system is perfect and we should not touch it. There are other options for bidi. (just my $0.02) Boaz - 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
