Here is a bug I found.
unlvsur unlvsur
unlvsur@live.com
Mon Mar 23 12:31:46 GMT 2020
That is not WSL2’s fault. Syscall is always expensive. Improving WSL2 does not solve anything. WSL2 uses socket for connection. 4096 bufsize is always too small. 4096 is stuck in 1980s. (std::deque was 4096 before it enters C++ standard library)
Now, CPU is much faster however syscall is even more expensive due to extra safety checking.
65536 is a fair number for most platform now.
1048576 should be the number on Windows since windows syscall is even more expensive.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Florian Weimer<mailto:fw@deneb.enyo.de>
Sent: Monday, March 23, 2020 08:24
To: unlvsur unlvsur via Libstdc++<mailto:libstdc++@gcc.gnu.org>
Cc: unlvsur unlvsur<mailto:unlvsur@live.com>
Subject: Re: Here is a bug I found.
* unlvsur unlvsur via Libstdc:
> Glibc has a bug on WSL2 because of BUFSIZ being too small when you
> do any file I/O on WSL2 with different DOS hard drives. It will
> freeze I/O. For WSL2, 4096 is too small. 65536 is the minimal
> requirement. It will freeze the PC and probably cause the hypervisor
> to crash.
Then whatever mechanism WSL2 uses to pass I/O to the host needs to
perform more aggressive readahead. This is something that needs to be
fixed in WSL2, not every application separately.
More information about the Libstdc++
mailing list