[PATCH 1/4] win32u: Add freelist cache allocator.
Rémi Bernon
rbernon at codeweavers.com
Tue Mar 22 03:43:04 CDT 2022
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. 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?
--
Rémi Bernon <rbernon at codeweavers.com>
More information about the wine-devel
mailing list