On Sunday 10 June 2007, Jörn Engel wrote: > On Sun, 10 June 2007 18:27:49 +0200, Arnd Bergmann wrote: > > On Sunday 03 June 2007, Jörn Engel wrote: > > How about using submit_bio here instead of going to the page cache? > > That would avoid doubling all the memory consumption here. > > That may make sense, yes. "May", because there is no simple mapping > between physical data and logical data. In ext3, everything is > block-aligned, usually to 4KiB == PAGE_SIZE. So the exact same content > would exists in two pages. In LogFS, data is compressed and > byte-aligned. A bdev page can contain several full objects that after > uncompression get stored in one page each. Then maybe the submit_bio logic should only be done for the ->write path, not for ->read. The data that gets written out should already be present in the page cache for the files, so there is not much point having again, while you can see the read path as blockdev readahead: When you read a physical block that contains a logical block, it's likely to also contain part of another logical block that is going to be read in the near future. This way, you would also get exclusively clean pages in the block device address_space, which can be easily discarded. Also, maintaining correct ordering between write requests can be done easier if you insert the bios directly, instead of waiting for the lru writeback. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
