On Thu, Aug 13, 2020 at 3:31 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Thu, Aug 13, 2020 at 03:09:37PM -0700, Peter Collingbourne wrote: > > In order to measure the performance and RSS impact of reference pages, > > a version of this patch backported to kernel version 4.14 was tested on > > a Pixel 4 together with a modified [2] version of the Scudo allocator > > that uses reference pages to implement pattern initialization. A > > PDFium test program was used to collect the measurements like so: > > > > $ wget https://static.docs.arm.com/ddi0487/fb/DDI0487F_b_armv8_arm.pdf > > $ /system/bin/time -v ./pdfium_test --pages=1-100 DDI0487F_b_armv8_arm.pdf > > > > and the median of 100 runs measurement was taken with three variants > > of the allocator: > > > > - "anon" is the baseline (no pattern init) > > - "memset" is with pattern init of allocator pages implemented by > > initializing anonymous pages with memset > > - "refpage" is with pattern init of allocator pages implemented > > by creating reference pages > > > > All three variants are measured using the patch that I linked. "anon" > > is without the patch, "refpage" is with the patch and "memset" is > > with a previous version of the patch [3] with "#if 0" in place of > > "#if 1" in linux.cpp. The measurements are as follows: > > > > Real time (s) Max RSS (KiB) > > anon 2.237081 107088 > > memset 2.252241 112180 > > refpage 2.243786 107128 > > > > We can see that RSS for refpage is almost the same as anon, and real > > time overhead is 44% that of memset. > > Umm. These numbers aren't all /that/ compelling. memset takes 0.7% > longer than the baseline and consumes 4.8% more memory. I was expecting > better, to be honest ;-( It really depends on your environment and the program that you're running. 5% can go a long way on memory constrained hardware like low-end phones. And the number will go higher if the program makes sparse use of its allocations. Peter
