On Mon, Mar 21, 2022 at 05:41:48AM +0900, Jinoh Kang wrote:
> Signed-off-by: Jinoh Kang <jinoh.kang.kr@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.