On Tue, Feb 18, 2025 at 12:42:19PM -0800, Caleb Sander Mateos wrote: > Right, that's a good point that there's a tradeoff. I think always > allocating space for IO_CACHED_BVECS_SEGS bvecs is reasonable. Maybe > IO_CACHED_BVECS_SEGS should be slightly smaller so the allocation fits > nicely in a power of 2? Currently it looks to take up 560 bytes: > >>> 48 + 16 * 32 > 560 > > Using IO_CACHED_BVECS_SEGS = 29 instead would make it 512 bytes: > >>> 48 + 16 * 29 > 512 Right, and it's even smaller on 32-bit architectures. I don't think it's worth optimizing the cached object size like this. It's probably better we optimize for a particular transfer size. If your bvec is physically discontiguous, 32 bvecs gets you to 128k transfers on a 4k page platform. That seems like a common transfer size for benchmarking throughput. It is arbitrary at the end of the day, so I'm not set on that if there's an argument for something different.
