On 6/17/21 12:15 AM, Alexander Duyck wrote:
On Wed, Jun 16, 2021 at 12:10 AM Gavin Shan <gshan@xxxxxxxxxx> wrote:
On 6/15/21 12:26 PM, Alexander Duyck wrote:
On Mon, Jun 14, 2021 at 4:03 AM David Hildenbrand <david@xxxxxxxxxx> wrote:
On 11.06.21 09:44, Gavin Shan wrote:
On 6/1/21 6:01 PM, David Hildenbrand wrote:
On 01.06.21 05:33, Gavin Shan wrote:
[...]
Yes, generally reporting pages comes at a fairly high cost so it is
important to find the right trade-off between the size of the page and
the size of the batch of pages being reported. If the size of the
pages is reduced it maybe important to increase the batch size in
order to avoid paying too much in the way of overhead.
The other main reason for holding to pageblock_order on x86 is to
avoid THP splitting. Anything smaller than pageblock_order will
trigger THP splitting which will significantly hurt the performance of
the VM in general as it forces it down to order 0 pages.
Alex, Thanks for your reply and sorry for taking your time to this
discussion.
Could you please confirm it's PAGE_REPORTING_CAPACITY or the budget
used in page_reporting_cycle() when you're talking about "batch"?
Yes, when I refer to batch it is how many pages we are processing in a
single call. That is limited by PAGE_REPORTING_CAPACITY.
Alex, It seems the batch mechanism is to avoid heavy contention on
zone's lock if I'm correct? The current design is to report all pages
in the corresponding free list within 17 calls to page_reporting_cycle().
Could you please explain why 17 was chosen? :)
budget = DIV_ROUND_UP(area->nr_free, PAGE_REPORTING_CAPACITY * 16);
It's related to the magic number ("16"). With the threshold is decreased,
for example from 512MB to 2MB on arm64 with 64KB base page size, more
page reporting activities will be introduced. From this regard, it's
reasonable to increase the magic number as well, so that more calls
to page_reporting_cycle() to avoid the contention to zone's lock.
If you agree, I will come up with something, similar to what we do for
the threshold. However, I'm not sure if 64 is reasonable cycles to have
for this particular case.
in arch/arm64/include/asm/page.h
#ifdef CONFIG_ARM64_64K_PAGES
#define PAGE_REPORTING_ORDER 5
#define PAGE_REPORTING_CYCLES 64
#endif
in mm/page_reporting.h
#ifndef PAGE_REPORTING_CYCLES
#define PAGE_REPORTING_CYCLES 16
#endif
in mm/page_reporting.c::page_reporting_cycle()
budget = DIV_ROUND_UP(area->nr_free,
PAGE_REPORTING_CAPACITY * PAGE_REPORTING_CYCLES);
Thanks,
Gavin
