Re: [PATCH 2/4] ntdll: Provide more accurate virtual memory counters.
Out of curiosity, is there a particular application that depends on this behavior? It could be argued that reporting the value from the native operating system is better because it tells what's really happening in the process. -Alex
On Sun, 4 Jun 2017 22:51:10 -0600, Alex Henrie wrote:
Out of curiosity, is there a particular application that depends on this behavior? It could be argued that reporting the value from the native operating system is better because it tells what's really happening in the process.
-Alex
Good question. I'm trying to fix Sorcery Jokers (trial) issue, bug 43119. The application repeatedly trys to allocate virtual memory as much as possible, and measures available memory size by GlobalMemoryStatusEx(). This patch is better than nothing. The application stops memory allocation about 384MB (0x17ffffff) free. After the allocation, it succeeds to load libGL.so. However, it shows driver pointer missing error when loading DRI driver, radeonsi_dri.so. I'm still in trouble with this point. By the way, I have another idea about this issue. That is reserving virtual memory area when loading wined3d.dll and release it just before loading OpenGL libraries. Being hackish idea, I chose the forementioned method in the beginning. What do you think about these ideas? Akihiro Sagawa
2017-06-05 16:15 GMT+02:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>:
On Sun, 4 Jun 2017 22:51:10 -0600, Alex Henrie wrote:
Out of curiosity, is there a particular application that depends on this behavior? It could be argued that reporting the value from the native operating system is better because it tells what's really happening in the process.
-Alex
Good question. I'm trying to fix Sorcery Jokers (trial) issue, bug 43119. The application repeatedly trys to allocate virtual memory as much as possible, and measures available memory size by GlobalMemoryStatusEx().
This patch is better than nothing. The application stops memory allocation about 384MB (0x17ffffff) free. After the allocation, it succeeds to load libGL.so. However, it shows driver pointer missing error when loading DRI driver, radeonsi_dri.so. I'm still in trouble with this point.
By the way, I have another idea about this issue. That is reserving virtual memory area when loading wined3d.dll and release it just before loading OpenGL libraries. Being hackish idea, I chose the forementioned method in the beginning.
As far as hacks go, does adding some arbitrary "reserved" amount to pvmi.VirtualSize make any difference?
On Mon, 5 Jun 2017 19:41:06 +0200, Matteo Bruni wrote:
2017-06-05 16:15 GMT+02:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>:
On Sun, 4 Jun 2017 22:51:10 -0600, Alex Henrie wrote:
Out of curiosity, is there a particular application that depends on this behavior? It could be argued that reporting the value from the native operating system is better because it tells what's really happening in the process.
-Alex
Good question. I'm trying to fix Sorcery Jokers (trial) issue, bug 43119. The application repeatedly trys to allocate virtual memory as much as possible, and measures available memory size by GlobalMemoryStatusEx().
This patch is better than nothing. The application stops memory allocation about 384MB (0x17ffffff) free. After the allocation, it succeeds to load libGL.so. However, it shows driver pointer missing error when loading DRI driver, radeonsi_dri.so. I'm still in trouble with this point.
By the way, I have another idea about this issue. That is reserving virtual memory area when loading wined3d.dll and release it just before loading OpenGL libraries. Being hackish idea, I chose the forementioned method in the beginning.
As far as hacks go, does adding some arbitrary "reserved" amount to pvmi.VirtualSize make any difference?
Thanks comments. Could you explain why adding "reserved" amount to pvmi.VirtualSize helps the issue?
From my viewpoint, if we increase pvmi.VirtualSize, available virtual memory, i.e. MEMORYSTATUSEX.ullAvailVirtual, will decline. And, VM allocation limit doesn't change.
Thanks in advance, Akihiro Sagawa
2017-06-06 17:35 GMT+02:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>:
On Mon, 5 Jun 2017 19:41:06 +0200, Matteo Bruni wrote:
2017-06-05 16:15 GMT+02:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>:
On Sun, 4 Jun 2017 22:51:10 -0600, Alex Henrie wrote:
Out of curiosity, is there a particular application that depends on this behavior? It could be argued that reporting the value from the native operating system is better because it tells what's really happening in the process.
-Alex
Good question. I'm trying to fix Sorcery Jokers (trial) issue, bug 43119. The application repeatedly trys to allocate virtual memory as much as possible, and measures available memory size by GlobalMemoryStatusEx().
This patch is better than nothing. The application stops memory allocation about 384MB (0x17ffffff) free. After the allocation, it succeeds to load libGL.so. However, it shows driver pointer missing error when loading DRI driver, radeonsi_dri.so. I'm still in trouble with this point.
By the way, I have another idea about this issue. That is reserving virtual memory area when loading wined3d.dll and release it just before loading OpenGL libraries. Being hackish idea, I chose the forementioned method in the beginning.
As far as hacks go, does adding some arbitrary "reserved" amount to pvmi.VirtualSize make any difference?
Thanks comments. Could you explain why adding "reserved" amount to pvmi.VirtualSize helps the issue? From my viewpoint, if we increase pvmi.VirtualSize, available virtual memory, i.e. MEMORYSTATUSEX.ullAvailVirtual, will decline. And, VM allocation limit doesn't change.
As I understood your previous email, it sounded like the application allocates memory until the free memory amount gets to some particular value. By "faking" a lower free memory amount the application might stop allocating earlier and leave enough addressing space for native libraries. Does it make sense? Did I misunderstand something?
I also would like to point out that APCs can lead to a significant performance decrease when an application like a taskmanager or anticheat tool queries these values multiples times per second for all/multiple processes. The wineserver already has a list of committed memory allocated through NtAllocateVirtualMemory (see add_mapping_committed_range wineserver call). Maybe it is possible to satisfy the application using these values without interrupting running processes. I also wanted to take a look at the problem, but the download links are either broken or very unreliable. Regards, Michael
2017-06-05 8:15 GMT-06:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>:
On Sun, 4 Jun 2017 22:51:10 -0600, Alex Henrie wrote:
Out of curiosity, is there a particular application that depends on this behavior? It could be argued that reporting the value from the native operating system is better because it tells what's really happening in the process.
-Alex
Good question. I'm trying to fix Sorcery Jokers (trial) issue, bug 43119. The application repeatedly trys to allocate virtual memory as much as possible, and measures available memory size by GlobalMemoryStatusEx().
This patch is better than nothing. The application stops memory allocation about 384MB (0x17ffffff) free. After the allocation, it succeeds to load libGL.so. However, it shows driver pointer missing error when loading DRI driver, radeonsi_dri.so. I'm still in trouble with this point.
When I try to run that game, I get "Failed to load libGL: libGL.so.1: failed to map segment from shared object" with or without your patchset. I also tried adding 100, 500, and 1000 MB to pvmi->VirtualSize and pvmi->PeakVirtualSize and that didn't help either. So, although this patchset is interesting, I'm not convinced that it's the right solution. There must be something else going on. -Alex
On Tue, 6 Jun 2017 17:40:26 -0600, Alex Henrie wrote:
When I try to run that game, I get "Failed to load libGL: libGL.so.1: failed to map segment from shared object" with or without your patchset.
I also tried adding 100, 500, and 1000 MB to pvmi->VirtualSize and pvmi->PeakVirtualSize and that didn't help either.
So, although this patchset is interesting, I'm not convinced that it's the right solution. There must be something else going on.
-Alex
Thanks for testing and feedback. Indeed, it needs some improvements. I'll find out more about tihs issue. Akihiro Sagawa
participants (4)
-
Akihiro Sagawa -
Alex Henrie -
Matteo Bruni -
Michael Müller