On 4/2/2024 3:35 PM, Martin Wege via Cygwin wrote:
On Tue, Apr 2, 2024 at 3:17 PM Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
On Apr 2 02:04, Martin Wege via Cygwin wrote:
Hello,
Is there any document which describes how Cygwin and Win32 file
prefetch and readahead work, and which sizes are used (e.g. always
read one full page even if only 16 bytes are requested?)?
I'm not aware of any docs, but again, keep in mind that Cygwin is a
usersapce DLL. We basically do what Windows does for low-level file
access.
Quick /usr/bin/stat /etc/profile returns "IO Block: 65536". Does that
mean the file's block size is really 64k? Is this info per filesystem,
or hardcoded in Cygwin?
Hardcoded in Cygwin since 2017, based on a discussion in terms of
file access performance, especially when using stdio.h functions:
https://cygwin.com/cgit/newlib-cygwin/commit/?id=7bef7db5ccd9c
OUCH.
While I can understand the motivation, FAT32 on multi-GB-devices
having 64k block size, and Win32 API on Win95/98/ME/Win7 being
optimized to that insane block size, it is absolutely WRONG with
today's NTFS and even more so with ReFS. This only works if you stream
files, but as soon as you are doing random read/writes the performance
is terrible due to cache thrashing. That could explain the many
complaints about Cygwin's IO performance.
No comment.
So, what can be done? I'm not a benchmarking guru, so I'd like to
propose to add a tunable called EXPERIMENTAL_PREFERRED_IO_BLKSIZE to
the CYGWIN env variable (marked as "experimental"), so the
benchmarking guys can do performance testing without recompiling
everything, get perf results for Cygwin 3.6, and decide what to do for
Cygwin 3.7.
That kind of experiment is what folks who can build their own
cygwin1.dll might do. I doubt we'd want to make a run-time global disk
I/O strategy changer available like this, even temporarily.
What could make sense is enhancing Cygwin's posix_fadvise() to support
POSIX_FADV_RANDOM getting mapped to Windows' FILE_RANDOM_ACCESS flag.
Something like this is currently done for POSIX_FADV_SEQUENTIAL ->
FILE_SEQUENTIAL_ONLY. These are per-filedescriptor adjustments and due
to Windows limitations would apply to a whole file rather than having
the POSIX behavior of being settable for a byte range within a file.
SHTDI, PTC, and all that :-).
..mark
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
