High CPU usage (slow thread lock) after reading gzip file #3697
Labels
Comments
wangqr
changed the title
|
From the strace this is likely because gettimeofday() with WSL is a syscall, whereas on regular Linux it is a read from a special memory location. There are multiple issues in #77, but this is one of them. |
|
Again fwiw (two in one day), the unmentionable other thread was/is I have a better-than-even suspicion there is something "new" here, and it won't be explained (in whole) by |
|
Here is the the Blockage looks like the snippit below. I strongly suspect the This is The OP trace looks like: |
|
Thanks @therealkenc -- I took a closer look at this and I believe the difference is due to the fact that we are delivering the signal to a different thread than Linux. Our signal policy is essentially first available thread in the threadgroup, but running a test on Linux it appears to favor the parent thread for SIGCHLD. |
|
I am going to call the signal targeting issue a red-herring (interesting, but not causing this issue). It looks like the problem here is simply that clone() is really slow. Now clone() on WSL is certainly going to be slower than on Linux because this is one of the most challenging emulation points. But slow should be on the order of one second, whereas in the strace it is 8-9 seconds. Maybe this is a one proc VM, where the repeated futex attempt by the other thread is exacerbating the slowness. At any rate the strace from this perspective looks like: ~8.5 secs passes spinning on the futex with 5ms sleeps until the clone completes and the futex is signaled. |
|
Aright - probably disregard the |
|
Here is the strace with timestamps. The |
|
@wangqr How many processors does the repro environment have? If more than one, can you try disabling any anti-virus software and rerunning the test. |
|
The WSL repro environment is a fresh installed Windows insider, and Ubuntu from Store, on i5-4258u (2C4T), with Windows Defender turned on. The Linux repro environment is an Archlinux on N3050. I can rerun the test tomorrow with Defender turned off. |
|
test.strace.wsl_18329_defender_off.zip
|
|
WSL 2 on build 18917 does not have this issue. |
|
I just diagnosed a similar pathology with GN building fuchsia under wsl 1 and found that swapping out for tcmalloc mitigates the issue. It seems that the way that glibc's allocator is marking pages is pathological for the clone emulation, whereas tcmallocs doesn't have the problem. |
|
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request. Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Microsoft Windows [Version 10.0.17763.134] with Archlinux and python 3.7.1
Also reproducible on 10.0.18290.1000 with Ubuntu 18.04 and python 3.6.5, fresh installed from Microsoft store.
This python script will run 2 threads. One thread
sudo_loop()runs a sub process each second. The other threaddummy()loads a gzip file, then sleep for a long time.On a linux machine, after the second thread goes to sleep, the CPU usage is nearly 0.
On WSL, the
python3process will constantly have high CPU usage. This can be seen in htop, or taskmgr if WSL becomes too laggy or hang.This issue is originally opened at actionless/pikaur#317. In the original issue, the first thread runs
sudo -veach second. The second thread will call some functions inlibalpm, which eventually loads a gzip file withlibarchive(a C library to open archive. The gzip module in python does NOT depend onlibarchive, but both of them depend onzlibto open gzip files) then waits for user input.strace: strace.zip
This strace is generated on windows 18290 with Ubuntu 18.04. Strace cannot be used on 17763 due to #3695
The text was updated successfully, but these errors were encountered: