[PATCH 1/4] ntdll: Increase step after failed map attempt in try_map_free_area().

Paul Gofman pgofman at codeweavers.com
Thu Aug 6 10:51:00 CDT 2020


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




More information about the wine-devel mailing list