On 12/24/19 3:23 PM, Paul Gofman wrote:
On 12/24/19 16:17, Rémi Bernon wrote:
On 12/24/19 1:27 PM, Alexandre Julliard wrote:
The original patches this whole zero bits thing is based upon were trying semi-random addresses to try to find free system areas, with a timeout [1], but I'm not completely convinced that it's better especially with the top_down flag to implement.
It could also read /proc/self/maps, making it not portable, I guess. Or maybe there's a way to enumerate mapped memory, including non-Wine, that I'm missing?
Just to mention, there is also an mincore() system call which I suppose should be portable which can provide a preliminary guess if the range of pages is free. It should be much less expensive than an attempt to map a memory at least because the attempt always succeeds allocating the memory outside of the region which is then freed in case memory is busy. This is still not transactional of course (native code in separate threads can get the memory right after checking it availability either way).
Alright, I didn't know that, thanks.
Or you just mean the search within an expected free area could do a bisection instead of iterating linearly?
There are some applications which depend on (virtual) memory allocations not returning high addresses while the lower memory is available. Windows allocates virtual memory bottom up unless top down is explicitly requested. I made a patch [1] some time ago which does that the same way zero_bits allocation works (that depends on this fix or equivalent). Unless such sort of change is not desirable for some reason it would be great if the modified fix for zero_bits support would keep the ability to follow bottom up / top down allocation order.
Sure, and by bisection I rather meant that -assuming the requested size is greater than the alignment- you can probably start iterating with a bigger step to have a coarse estimate before trying to find a more precise location.