https://bugs.winehq.org/show_bug.cgi?id=58000
Bug ID: 58000 Summary: New thread stack uses too much memory Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: piotr.caban@gmail.com Distribution: ---
Created attachment 78261 --> https://bugs.winehq.org/attachment.cgi?id=78261 simple app that can be used to reproduce the problem
It's a regression caused by 3863b243fe5ef4e223a809e93a85e858952dd754 commit. Affected application (32-bit) runs on low end machine and creates 128 cores. Prior to this change it was using ~34MB of memory, in wine 10.0 it uses ~152MB (every thread uses ~1MB for stack). I've also confirmed that application memory usage is small on Windows 10.
According to MSDN stack should not use physical memory until it's referenced.
https://bugs.winehq.org/show_bug.cgi?id=58000
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |3863b243fe5ef4e223a809e93a8 | |5e858952dd754 Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=58000
--- Comment #1 from Alexandre Julliard julliard@winehq.org --- The size was already reduced in 96f5968a651609aa22ba482d4b244e6599095735, it could probably be reduced more.
https://bugs.winehq.org/show_bug.cgi?id=58000
--- Comment #2 from Piotr Caban piotr.caban@gmail.com --- I've reached out to the machines owner hoping to determine what's the maximum size that will make it functional. I didn't receive any reply yet. I'll update the bug when I have more information.
https://bugs.winehq.org/show_bug.cgi?id=58000
--- Comment #3 from Piotr Caban piotr.caban@gmail.com --- Here's the info I have received: - the system has 2GB of RAM - non-wine components are using ~700MB - old wine without 3863b243fe5ef4e223a809e93a85e858952dd754 commit uses ~500MB - the application starts over 1k wine threads
Unfortunately I didn't get memory usage with current wine but I guess it's something around 700+500+1000*0.9 = 2100. I guess that reducing zeroed area size by ~10-20% should do the job (unless there's a better solution).