Markus Schaber <m.scha...@codesys.com> writes:
> Hi, Evgeny,
>
> Great work, IMHO.
Thank you :-)
>> This patch series reduces the amount of syscalls in such situations by
>> performing a single WriteFile() call without any buffering, if possible.
>> If some data is already buffered, then the buffer is first filled, flushed
>> and the remaining part of the data is written with a single WriteFile().
>
> Why first refilling the buffer, instead of flushing the partial buffer
> content, and then the original data to write?
>
> From my first glance, it looks like the number of syscalls should be
> the same, and we could skip the mem copy?
My original intention here was to avoid issuing small and non-4K-sized
writes, which could happen if we don't refill the buffer.
For instance, in the example above doing so would result in
WriteFile(13)
WriteFile(86267)
WriteFile(13)
WriteFile(86400)
...
instead of
WriteFile(4096)
WriteFile(82185)
WriteFile(4096)
WriteFile(82317)
...
But I should also say that I ran a couple of tests and I can't see any
measurable performance difference between these two approaches, so it
might indeed make sense to switch to the first of them and avoid a memcpy().
In the meanwhile, apparently, there is an oversight in the core V1 patch
(3-reduce-syscalls-for-buffered-writes-v1.patch.txt):
If the buffer is not empty, and the caller issues a write with a chunk
that slightly exceeds the buffer size, for example, 4100 bytes, it would
result in flushing the buffer _and_ writing the remaining couple of bytes
with WriteFile(). An appropriate thing to do here would be to flush the
buffer, but put the few remaining bytes into the buffer, instead of writing
them to disk and thus making an unnecessary syscall.
With all this in mind, I will prepare the V2 version of the core patch.
Thanks,
Evgeny Kotkov
