[PATCH 1/4] win32u: Add freelist cache allocator.

[Paul Gofman]

Did you compare the actual performance on some test cases to just 
memsetting the whole area before doing the blit? In my experience on 
Linux pre-faulting the memory this way reduce the overhead greatly, 
while the benefit of explicit huge pages management over this is not 
apparent. It is not obvious that caching large memory areas in gdi32 
worth it given VM address exhaustion issues we have with a bunch of 32 
bit apps. IMO if something like this is absolutely necessary that should 
be somehow considered on ntdll VM level so such a memory can be reclaimed.

On 3/22/22 12:06, Jinoh Kang wrote:
>
>> In my experience transparent huge pages solve this, unless the access pattern is bad (like pages touched backwards). In which case, memsetting the pages would be sufficient (for large blocks we rely on VirtualAlloc allocating zeroed pages and we do not write to them).
>>
>> I believe most Linux distributions enable THP by default now, so if you disable them it's pretty much that you know what performance hit it can induce and I don't think Wine should try to mitigate it.
>>
>> Then there's the question about platforms without THP-like feature, which I'm not sure how common they are.
> The platform needs to either support THP, or the malloc() usage pattern of allocating and freeing large objects frequently.
>
>> If there's a portable (-ish) way to request pages larger than the default, when allocating virtual memory, that may be a better and more generic fix?
> I don't think such tunable would be portable, but I agree it's the best way forward if there is one.
>