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

[Jinoh Kang]

On 3/22/22 17:43, Rémi Bernon wrote:
> On 3/21/22 17:47, Jin-oh Kang wrote:
>> On Mon, Mar 21, 2022, 7:56 PM Huw Davies <huw at codeweavers.com> wrote:
>>
>>> On Mon, Mar 21, 2022 at 05:41:48AM +0900, Jinoh Kang wrote:
>>>> Signed-off-by: Jinoh Kang <jinoh.kang.kr at gmail.com>
>>>> ---
>>>>   dlls/win32u/Makefile.in     |   1 +
>>>>   dlls/win32u/alloc.c         | 173 ++++++++++++++++++++++++++++++++++++
>>>>   dlls/win32u/ntgdi_private.h |   4 +
>>>>   3 files changed, 178 insertions(+)
>>>>   create mode 100644 dlls/win32u/alloc.c
>>>
>>> Hi Jinoh,
>>>
>>> Could you provide some justification for why we should include this?
>>>
>>
>> Well, I forgot to mark this as RFC. I still haven't decided how to
>> benchmark this change effectively; feedbacks are welcome.
>>
>> The rationale was that some applications were seeing frequent page faults
>> due to writing to demand-zero pages in GDI bit blitting routines.
>>
>> For a bitmap that extends over several demand-zero pages, each page access
>> would incur a fault (in the worst scenario), resulting in significant
>> performance drop and/or high CPU usage. This may be aggravated by
>> non-sequential access (which usually is the case with bottom-up DIBs) or
>> with transparent huge pages disabled.
>>
> 
> 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.

> 

-- 
Sincerely,
Jinoh Kang