[PATCH 3/4] ntdll: Force virtual memory allocation order.

[Rémi Bernon]

On 2020-08-21 00:03, Paul Gofman wrote:
> On 8/21/20 00:47, Rémi Bernon wrote:
>>
>> I was thinking that we could do something like in the attached 
>> patches, where if the mapping in reserved areas failed in bottom up 
>> alloc, we reserve more memory and try again until it succeeds.
>>
>> I think it's simpler and the existing code already handles the 
>> reservation with bisecting steps nicely. Wouldn't that work?
>>
>> Of course this will cause some more memory to be definitively reserved 
>> for Windows, but that will then also be used as needed by following 
>> allocations.
>>
>> Alternatively we could release the over-reserved memory every time, 
>> but that also means we will have to reserve again on next allocations.
> 
> I guess something like that can work, but I don't understand how playing 
> harder with reserve areas is simpler or less hacky. But maybe its only me.
> 
> What will happen if there is a native mapping close to the previous 
> reserve area end and reserve_area() will shrink its size below the size 
> we need? Anyway, that can be solved some way by introducing a smarter 
> search probably between the lines of existing search in 
> try_map_free_area. And yeah, not immediately clear to me also if the 
> reserved areas are needed to given back or not.
> 
> What I can't understand yet, how it is simpler or better to increase 
> those free areas each time we run out of space with them (top down 
> allocs are rare, and there is no "don't care" flag). It IMO further 
> twists the "free area" - "reserved area" allocation duality.

Well the free ranges were mostly meant as an optimization over iterating 
the view tree, and they only track free addresses from the Windows point 
of view. The reserved area, are the addresses that Wine has reserved for 
its Windows usage, and that are so known not to be used by the system.

For me that works in the same way an allocator reserves larger blocks 
from the system virtual memory allocator, and then splits them in small 
blocks depending on the allocation requests that it will give to its 
clients.

> Does saving 
> a few lines in the patch (compared to the one which does a unified 
> search algorithm) worth all of it (even if it is still so after bringing 
> in some missing bits)?
>-- 
Rémi Bernon <rbernon at codeweavers.com>