On Fri, Aug 03, 2012 at 04:51:55PM -0400, Josef Bacik wrote: > We've been allocating a big array for csums instead of storing them in the > io_tree like we do for buffered reads because previously we were locking the > entire range, so we didn't have an extent state for each sector of the > range. But now that we do the range locking as we map the buffers we can > limit the mapping lenght to sectorsize and use the private part of the > io_tree for our csums. This allows us to avoid an extra memory allocation > for direct reads which could incur latency. Thanks,
This assumes the checksum value fits into the private state, ie sizeof(csum) == 4, sizeof(private) == 8. There are 32 bytes reserved for csum bytes, someday another algo will land, and will have to reintroduce the kmalloc in some way, but there will be more code changes needed. The assumptions about csum of u32 type are widespread. Getting rid of the kmalloc is a good idea, I think we should take this patch for now. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
