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. -- Jens Axboe - 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
