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

[Jin-oh Kang]

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.

Specifically, KakaoTalk renders GIF animations via GDI, calling
CreateCompatibleBitmap() a number of times per each frame. NtCreateBitmap()
uses calloc() to allocate bitmap memory, and calloc() uses freshly
mmap()-ed area above certain size threshold. Apparantly GLibc ptmalloc
assumes the use pattern where bigger objects are allocated and freed much
rarer.

Additionally, there are a few magic numbers in this patch, some
> discussion about their value would be good.
>

They are pretty arbitrary as you might have guessed. It certainly needs
more benchmark work so it can be tuned more appropriately.


> Also note, [1/4] is adding dead (unused) code.  You'd want to combine
> it with [2/4] say.
>

Ack.


> Huw.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220322/ae5d7bb6/attachment.htm>