Andrew Morton wrote: >We have one filesystem which wants such a refactoring (although I don't >think you've adequately spelled out _why_ reiser4 wants this). > > > When calling the filesystem for writes, there is processing that must be done: 1) per word 2) per page 3) per call to the FS If the FS is called per page, then it turns out that 3) costs more than 1) and 2) for sophisticated filesystems. As we develop fancier and fancier plugins this will just get more and more true. It decreases CPU usage by 2x to use per sys_write calls into reiser4 rather than per page calls into reiser4. (Vladimir, on Monday can you find and send your benchmarks?) This is significant for cached writes. If it violates the intuition to believe this, then let me point out that there was a similar motivation for the creation of bios: calling the block layer traverses more lines of code than copying a page of bytes does. Unfortunately, all that code turns out to be useful optimizations, so one cannot just take the attitude (whether for the block layer or reiser4) that it should just be simplified. Please note that I have no real problem with leaving the generic code unchanged and having reiser4 do its own write operation. I am modifying the generic code because you suggested it was preferred. Having reviewed the code in detail, I see that you were right and it is better to just fix the generic code to call more than 4k at a time into the FS, and then be able to reuse the generic aio and direct io code (and etc.) as a result. So, to be sociable, and to get more code reuse, we make this proposal. >To be able to say "yes, we want this" I think we'd need to understand which >other filesystems would benefit from exploiting it, and with what results? > > > > Or just let us have our own sys_write implementation without being excluded for it. I have shown that it is significantly faster for reiser4 to process things more than 4k at a time. - 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
