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. Additionally, remember that turning on redzoning, which seems to be quite popular nowadays, actually blows out the slab size calculations anyway. 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. James - 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
