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

[Paul Gofman]

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. 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)?