-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pthread workers 100% CPU usage... #22128
Comments
Can you share the full set of link flags you use? Do you know when this changed? Certainly this sounds like a regression. You can bisect on emsdk versions to find out what this broke https://emscripten.org/docs/contributing/developers_guide.html#bisecting (or even just tell is the version where it was not doing this and the first version where you noticed it?) |
I'm not exactly sure when this start happening, because normally i do not check workers in profiler. I think 3 month ago workers looked good in profiler, in idle state most of the time. This is the list of flags in build.ninja: FLAGS = -flto -frtti -DNDEBUG -s USE_SDL=2 -pthread -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=4 -O2 -gsource-map -Wno-unknown-pragmas -Wno-unused-function -Wno-deprecated-declarations -fvisibility=hidden -DTMRW_DEBUG=true -DTMU_PLUGINMANAGER_NO_DYNAMIC_PLUGIN_SUPPORT=1 -fcolor-diagnostics -DNDEBUG -fomit-frame-pointer -ffunction-sections -fdata-sections LINK_FLAGS = -s MODULARIZE -s EXPORT_NAME=createWasmEngine --bind -s WASM=1 -s ALLOW_MEMORY_GROWTH=1 -frtti -s USE_SDL=2 -s MIN_WEBGL_VERSION=2 -s MAX_WEBGL_VERSION=2 -s USE_WEBGL2=1 -s TEXTDECODER=0 -s ALLOW_BLOCKING_ON_MAIN_THREAD=1 -s ENVIRONMENT=web,worker -pthread -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=4 -O2 -gsource-map -s EXPORTED_FUNCTIONS=['_main','_malloc','_free','_onLoadURL'] -s EXPORTED_RUNTIME_METHODS=['ccall','cwrap','AsciiToString','allocate'] -s EXTRA_EXPORTED_RUNTIME_METHODS=['GL'] -Wl,-u,_emscripten_run_callback_on_thread -s USE_WEBGL2=1 |
The earliest emsdk i could rollback is 3.1.52. And the issue with busy workers still exists there. For now will have to temporariry disable pthreads engine... |
On the main thread See: emscripten/system/lib/pthread/emscripten_futex_wait.c Lines 129 to 133 in eb47e28
On worker threads See:
However, higher level API calls such a pthread_cond_wait will slice up the wait time and only wait for at most 100ms at a time. See emscripten/system/lib/libc/musl/src/thread/__timedwait.c Lines 64 to 65 in eb47e28
|
I'm not using wait in main thread. Please check the screenshots above. I'm talking about nearly 100% cpu usage in pthread function loop (ie Worker) where i use function: |
Can you point the where you think the busy loop is?
The calling function |
Ok, can you please explain profiler screenshot I showed in first post ? I dodn't know where is busy loop, because i'm not autor of emscripten code. I just wondering why worker code is busy 100% of the time when it should idle most of the time. |
I can't explain that no, those threads should only be waking up every 100ms, not busy-waiting. |
I understand that you are seeing a busywaiting thread.. I just can't explain it at this point. As far as we know the behaviour your are seeing has always been there, is that right? i.e. you can't find a version of emscripten that doesn't show this behaviour. If the problem is that the very low level in What is the UI you are using to grab those screenshots? I assume that is one part of chrome? |
As I mentioned earlier, several month ago i didn't see busy workers in my project. It was the opposite, threads where suspended, and I always tried to find the small piece of code executed in workers (i'm talking about chrome profiler here). But i don't know when it was changed. Moreover I don't know is this issue related to emscripten or there is bug in latest chrome profiler. But i assume if there is bug in profiler - why it shows correct expected result in pure js project workers? So I still think the issue is related to emsdk somehow... |
Ok, we checked the pthread workers on 3 different dev machines in chrome profiler. |
Hello,
Today I profiled my wasm engine (pthreads version) and found that all 4 threads (workers) of the job system take 100% CPU usage.
I used chrome profiler. Normally it shows nothing in workers (white bars) if thread is suspended. But in my case it shows usage in... emscripten_futex_wait. Isn't it suppose to suspend thread (sleep) in this function? Why it shows hundreds of millisecond CPU usage in waiting for conditional variable?
The text was updated successfully, but these errors were encountered: