* Cygwin&Win32 file prefetch, block sizes? @ 2024-04-02 0:04 Martin Wege 2024-04-02 13:16 ` Corinna Vinschen 0 siblings, 1 reply; 10+ messages in thread From: Martin Wege @ 2024-04-02 0:04 UTC (permalink / raw) To: cygwin 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?)? 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? Thanks, Martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-02 0:04 Cygwin&Win32 file prefetch, block sizes? Martin Wege @ 2024-04-02 13:16 ` Corinna Vinschen 2024-04-02 22:35 ` Martin Wege 0 siblings, 1 reply; 10+ messages in thread From: Corinna Vinschen @ 2024-04-02 13:16 UTC (permalink / raw) To: cygwin 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 Corinna ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-02 13:16 ` Corinna Vinschen @ 2024-04-02 22:35 ` Martin Wege 2024-04-03 1:10 ` Mark Geisert ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Martin Wege @ 2024-04-02 22:35 UTC (permalink / raw) To: cygwin 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. 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. Thanks, Martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-02 22:35 ` Martin Wege @ 2024-04-03 1:10 ` Mark Geisert 2024-04-03 6:44 ` Cedric Blancher 2024-04-03 5:21 ` Cedric Blancher 2024-04-03 8:14 ` Corinna Vinschen 2 siblings, 1 reply; 10+ messages in thread From: Mark Geisert @ 2024-04-03 1:10 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-03 1:10 ` Mark Geisert @ 2024-04-03 6:44 ` Cedric Blancher 2024-04-04 18:10 ` Brian Inglis 0 siblings, 1 reply; 10+ messages in thread From: Cedric Blancher @ 2024-04-03 6:44 UTC (permalink / raw) To: cygwin On Wed, 3 Apr 2024 at 03:10, Mark Geisert via Cygwin <cygwin@cygwin.com> wrote: > > 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. Realistically that would mean that Cygwin will forever be stuck with an insane IO block size. Building Cygwin.dll requires specialised knowledge and TIME, and no manager will waste the time of a performance engineer to produce custom binaries. Cygwin 3.6 is right now in development, so it would be better to add such a knob, so performance engineers can just grab those binaries and do benchmarking with them. BTW: A block size of 64k is CLEARLY harming performance. Have a look at https://www.zabkat.com/blog/buffered-disk-access.htm the sweet spot is somewhere between 16k and 32k, for SMB even below that. 64k is clearly on the backside of the curve, and actively harming performance, except for "linear reads". > > 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. Nope. Because we are talking about a sensible default for all applications, and a block size of 64k is HARMFUL, except on fat32 where the filesystem block size is already 64k for multi gigabyte disks. Ced -- Cedric Blancher <cedric.blancher@gmail.com> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-03 6:44 ` Cedric Blancher @ 2024-04-04 18:10 ` Brian Inglis 0 siblings, 0 replies; 10+ messages in thread From: Brian Inglis @ 2024-04-04 18:10 UTC (permalink / raw) To: cygwin On 2024-04-03 00:44, Cedric Blancher via Cygwin wrote: > On Wed, 3 Apr 2024 at 03:10, Mark Geisert via Cygwin wrote: >> 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 wrote: >>>> On Apr 2 02:04, Martin Wege via Cygwin wrote: >>>>> 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 >>>> userspace 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 Those 32 bit systems stopped being of interest long ago and 32 bit Windows and Win7 are no longer supported. >>> 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. Most Cygwin random read/writes are likely for directories. Any random file I/O is down to the application's needs. >> 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. > > Realistically that would mean that Cygwin will forever be stuck with > an insane IO block size. > > Building Cygwin.dll requires specialised knowledge and TIME, and no > manager will waste the time of a performance engineer to produce > custom binaries. > Cygwin 3.6 is right now in development, so it would be better to add > such a knob, so performance engineers can just grab those binaries and > do benchmarking with them. Benefit for majority of users to have volunteers do that, rather than address Cygwin issues and keep up to date with Windows releases? If they can pay for benchmarking and performance engineers, they can pay to make their own changes, and do their own builds. No one is saying they have issues and why, and want to bench Cygwin I/O and share their results with us. > BTW: A block size of 64k is CLEARLY harming performance. Have a look > at https://www.zabkat.com/blog/buffered-disk-access.htm the sweet spot > is somewhere between 16k and 32k, for SMB even below that. 64k is > clearly on the backside of the curve, and actively harming > performance, except for "linear reads". A decade ago in 2013! I have older papers recommending 4KB and 8KB blocks and pages, and other older papers from that same period recommending 40KB or track sized I/O. Remember Cygwin does its own directory reads so 64KB is probably about right for NTFS entries into dirent. Unless someone has done benchmarking to prove that some other number would be better in future, making it smaller probably does not make any sense. >> 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. > > Nope. Because we are talking about a sensible default for all > applications, and a block size of 64k is HARMFUL, except on fat32 > where the filesystem block size is already 64k for multi gigabyte > disks. Who uses FAT32 for large drives except maybe flash, not even then if they're smart? Even in the small, slow old days, the equivalent of readfile(2), and mmap(2) were better choices. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-02 22:35 ` Martin Wege 2024-04-03 1:10 ` Mark Geisert @ 2024-04-03 5:21 ` Cedric Blancher 2024-04-03 8:14 ` Corinna Vinschen 2 siblings, 0 replies; 10+ messages in thread From: Cedric Blancher @ 2024-04-03 5:21 UTC (permalink / raw) To: cygwin On Wed, 3 Apr 2024 at 00:36, Martin Wege via Cygwin <cygwin@cygwin.com> 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. > It can also explain why Cygwin is so slow on SMB filesystems. If it really works on 64k blocks, then this would pull all small files over the wire, even if only a bit gets touched. Thinking more about this, this basically defeats every driver/tcp/ip/ethernet/net/switch optimization like jumbo frames et al. /usr/bin/stat %o (optimum IO block size hint) also returns 65536 on SMB, which is NOT GOOD: This needs to be confirmed, and if this is really true, then it should be fixed for SMB. I need a coffee to think about this... > 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. I would agree, but I would also clamp the minimum at page size (4096 bytes on x86) and 8M (4x 2M hugepage size) to prevent abuse. Does Cygwin partake in the GSOC programm (Google Summer Of Code)? This would IMO be a high priority item. Ced -- Cedric Blancher <cedric.blancher@gmail.com> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-02 22:35 ` Martin Wege 2024-04-03 1:10 ` Mark Geisert 2024-04-03 5:21 ` Cedric Blancher @ 2024-04-03 8:14 ` Corinna Vinschen 2024-04-03 11:44 ` Corinna Vinschen 2024-04-03 17:42 ` Cedric Blancher 2 siblings, 2 replies; 10+ messages in thread From: Corinna Vinschen @ 2024-04-03 8:14 UTC (permalink / raw) To: cygwin On Apr 3 00:35, 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. The above patch *only* sets stat::st_blksize to 64K. Nothing else happens! This usually means that stdio.h functions use this size for their buffer and readahead. It doesn't affect direct calls to read(2)/write(2) and fread(3)/fwrite(3) at all! > 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 No. We have two ways to handle this *iff* there's really a reason to handle this. - Either we just lower PREFERRED_IO_BLKSIZE to 4K or 8K, but that's kind of bad in terms of pipes, the clipboard, etc. - So we keep PREFERRED_IO_BLKSIZE at 64K but don't use it for disk files. Rather, we read this info from the filesystem: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_fs_sector_size_information If the filesystem is local and SSINFO_FLAGS_NO_SEEK_PENALTY is set, we could stick to 64K. Otherwise the PhysicalBytesPerSectorForPerformance member might be helpful I guess. Needs checking, of course. If this isn't any good, we can still fallback to FILE_FS_FULL_SIZE_INFORMATION as in fhandler_base::fstatvfs_by_handle, https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fhandler/disk_file.cc#n661 Corinna ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-03 8:14 ` Corinna Vinschen @ 2024-04-03 11:44 ` Corinna Vinschen 2024-04-03 17:42 ` Cedric Blancher 1 sibling, 0 replies; 10+ messages in thread From: Corinna Vinschen @ 2024-04-03 11:44 UTC (permalink / raw) To: cygwin On Apr 3 10:14, Corinna Vinschen via Cygwin wrote: > https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_fs_sector_size_information > > If the filesystem is local and SSINFO_FLAGS_NO_SEEK_PENALTY is set, we > could stick to 64K. > > Otherwise the PhysicalBytesPerSectorForPerformance member might be > helpful I guess. Needs checking, of course. It's not helpful. This is the output for NTFS: (gdb) p ffssi $5 = {LogicalBytesPerSector = 512, PhysicalBytesPerSectorForAtomicity = 512, PhysicalBytesPerSectorForPerformance = 512, FileSystemEffectivePhysicalBytesPerSectorForAtomicity = 512, Flags = 11, ByteOffsetForSectorAlignment = 0, ByteOffsetForPartitionAlignment = 0} D'oh > If this isn't any good, we can still fallback to > FILE_FS_FULL_SIZE_INFORMATION as in fhandler_base::fstatvfs_by_handle, > https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fhandler/disk_file.cc#n661 So ffsi.BytesPerSector * ffsi.SectorsPerAllocationUnit is it then. But: > On Apr 3 00:35, Martin Wege via Cygwin wrote: > > 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. So this has supposedly changed with Win8. Where's that publically documented? Corinna ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin&Win32 file prefetch, block sizes? 2024-04-03 8:14 ` Corinna Vinschen 2024-04-03 11:44 ` Corinna Vinschen @ 2024-04-03 17:42 ` Cedric Blancher 1 sibling, 0 replies; 10+ messages in thread From: Cedric Blancher @ 2024-04-03 17:42 UTC (permalink / raw) To: cygwin; +Cc: Corinna Vinschen On Wed, 3 Apr 2024 at 10:15, Corinna Vinschen via Cygwin <cygwin@cygwin.com> wrote: > > On Apr 3 00:35, 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. > > The above patch *only* sets stat::st_blksize to 64K. Nothing else > happens! Yes, but applications use that information, and then make wrong choices. > > This usually means that stdio.h functions use this size for their buffer > and readahead. It doesn't affect direct calls to read(2)/write(2) and > fread(3)/fwrite(3) at all! > > > 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 > > No. > > We have two ways to handle this *iff* there's really a reason to > handle this. > > - Either we just lower PREFERRED_IO_BLKSIZE to 4K or 8K, but that's > kind of bad in terms of pipes, the clipboard, etc. I think the env variable was strictly meant for benchmarking **ONLY**, so someone with good benchmarking expertise can grab the Cygwin 3.6 alpha binaries and does benchmarking with them. > > - So we keep PREFERRED_IO_BLKSIZE at 64K but don't use it for disk > files. Rather, we read this info from the filesystem: > > https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_fs_sector_size_information @Corinna Vinschen Could you please do me a favour and check whether SMB supports FILE_FS_SECTOR_SIZE_INFORMATION? > > If the filesystem is local and SSINFO_FLAGS_NO_SEEK_PENALTY is set, we > could stick to 64K. That still means that buffers will be very large, and associated memcpy(), read(), write() are large too. Also harmful is that such buffers might be allocated with alloca(), because the original authors didn't anticipate 64k buffer sizes... > > Otherwise the PhysicalBytesPerSectorForPerformance member might be > helpful I guess. Needs checking, of course. > > If this isn't any good, we can still fallback to > FILE_FS_FULL_SIZE_INFORMATION as in fhandler_base::fstatvfs_by_handle, > https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fhandler/disk_file.cc#n661 You mean when FILE_FS_SECTOR_SIZE_INFORMATION is not supported you use FILE_FS_FULL_SIZE_INFORMATION instead? Ced -- Cedric Blancher <cedric.blancher@gmail.com> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-04-04 18:10 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-02 0:04 Cygwin&Win32 file prefetch, block sizes? Martin Wege 2024-04-02 13:16 ` Corinna Vinschen 2024-04-02 22:35 ` Martin Wege 2024-04-03 1:10 ` Mark Geisert 2024-04-03 6:44 ` Cedric Blancher 2024-04-04 18:10 ` Brian Inglis 2024-04-03 5:21 ` Cedric Blancher 2024-04-03 8:14 ` Corinna Vinschen 2024-04-03 11:44 ` Corinna Vinschen 2024-04-03 17:42 ` Cedric Blancher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).