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