[BUG FIX] Fix compilation of small UNet crashes with 2026.0 and later on 16GB MTL - #36435
[BUG FIX] Fix compilation of small UNet crashes with 2026.0 and later on 16GB MTL#36435sunxiaoxia2022 wants to merge 8 commits into
Conversation
…rkers to calculate scratchpad memory size
|
Hi, @sunxiaoxia2022 : Since this change also modifies oneDNN, could you please create a dedicated oneDNN fork PR to facilitate the review process? |
hi @liubo-intel I created an oneDNN PR: openvinotoolkit/oneDNN#316 |
|
@liubo-intel , could you please take a look once again? |
There was a problem hiding this comment.
Pull request overview
Fixes a CPU plugin crash/OOM during model compilation (oneDNN primitive descriptor creation) when using OV_THREAD_TBB_ADAPTIVE with the TBB partitioner in AUTO mode, by preventing oneDNN scratchpad planning from using inflated “virtual” concurrency.
Changes:
- Set oneDNN scratchpad concurrency to the real worker-thread count while keeping max concurrency aligned with the (possibly virtual) scheduling concurrency under
AUTO.
| // oneDNN uses this value when estimating scratchpad outside an active parallel region. | ||
| // Keep it aligned with the real worker pool size: AUTO may raise max_concurrency via | ||
| // virtual threads for scheduling, but scratchpad is still needed only for worker threads. | ||
| dnnl_threadpool_interop_set_scratchpad_concurrency(get_num_worker_threads()); |
|
This PR LGTM as a temporary fix for the concrete issue at hand. That said, it might be helpful to leave a TODO or follow-up tracking item for the other scratchpad-related sizing paths that haven't been migrated yet. @maxnick , what's your opinion on this? |
I would rather agree with our colleagues from oneDNN. It's better to ask the oneDNN team to fix this issue on their side than modify interfaces in our fork. |
|
Waiting for a proper fix on the oneDNN side. |
Details:
Root cause:
This issue only happens with
TBB_ADAPTIVEwhen the CPU partitioner runs inAUTOmode.In that configuration, the CPU plugin may expose inflated virtual concurrency during oneDNN descriptor creation, while descriptor planning should only see real worker-thread concurrency.
Some oneDNN primitives use the visible concurrency to decide implementation details and scratchpad size.
As a result, descriptors could be built against an inflated thread count, which amplified scratchpad requirements and caused large memory allocations.
Related oneDNN PR: openvinotoolkit/oneDNN#316
Tickets: