Re: batched write

[Hans Reiser <reiser@namesys.com>]

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.