On 8/6/20 18:22, Rémi Bernon wrote:
On 2020-07-23 18:32, Paul Gofman wrote:
Signed-off-by: Paul Gofman pgofman@codeweavers.com
dlls/ntdll/unix/virtual.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/ntdll/unix/virtual.c b/dlls/ntdll/unix/virtual.c index 883e5cff927..7b33b3e82ac 100644 --- a/dlls/ntdll/unix/virtual.c +++ b/dlls/ntdll/unix/virtual.c @@ -1033,6 +1033,7 @@ static void* try_map_free_area( void *base, void *end, ptrdiff_t step, step == 0) break; start = (char *)start + step; + step *= 2; } return NULL;
Could we use mincore as a better search heuristic, like what was suggested before, instead of this which doesn't feel very right?
I though of that and even experimented with mincore() a bit at some moment.
First of all, the information that we care for from mincore() is its return status, which tells us if there is any page mapped in the requested range or not. So we can't use it like, e. g., query the range and understand which is the last page mapped to jump accordingly. We can only know if there is some page mapped in the range. Which of course still makes possible to query the memory range which is quicker than performing mmap() with OS chosen address, but that is the case on non-Linux archs only where we don't have MMAP_FIXED_NOREPLACE flag. We could potentially introduce some algorithm for probing parts of the (already failed) mmap range to set the step in a more accurate way, but that will cost, as mincore() is also taking some time in kernel and involves VMA read locking. So it looks like whatever we do here, it won't work as a sole measure to solve the performance issues with native mapping conflicts. The major performance impact circumvention is the last patch in the series. Yet some measurable slowdown was observed while crawling through long native mapped area (before they all will end up marked). Increasing the step is effective and very simple solution.
Do you feel like I am missing some sensible way to use mincore() to this part better?