<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 21, 2022, 7:56 PM Huw Davies <<a href="mailto:huw@codeweavers.com" target="_blank" rel="noreferrer">huw@codeweavers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 21, 2022 at 05:41:48AM +0900, Jinoh Kang wrote:<br>
> Signed-off-by: Jinoh Kang <<a href="mailto:jinoh.kang.kr@gmail.com" rel="noreferrer noreferrer" target="_blank">jinoh.kang.kr@gmail.com</a>><br>
> ---<br>
>  dlls/win32u/Makefile.in     |   1 +<br>
>  dlls/win32u/alloc.c         | 173 ++++++++++++++++++++++++++++++++++++<br>
>  dlls/win32u/ntgdi_private.h |   4 +<br>
>  3 files changed, 178 insertions(+)<br>
>  create mode 100644 dlls/win32u/alloc.c<br>
<br>
Hi Jinoh,<br>
<br>
Could you provide some justification for why we should include this?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Well, I forgot to mark this as RFC. I still haven't decided how to benchmark this change effectively; feedbacks are welcome.</div><div dir="auto"><br></div><div dir="auto">The rationale was that some applications were seeing frequent page faults due to writing to demand-zero pages in GDI bit blitting routines.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Additionally, there are a few magic numbers in this patch, some<br>
discussion about their value would be good.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">They are pretty arbitrary as you might have guessed. It certainly needs more benchmark work so it can be tuned more appropriately.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also note, [1/4] is adding dead (unused) code.  You'd want to combine<br>
it with [2/4] say.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Ack.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Huw.</blockquote></div></div></div>