| From: |
| Mel Gorman <mgorman-AT-techsingularity.net> |
| To: |
| Andrew Morton <akpm-AT-linux-foundation.org> |
| Subject: |
| [PATCH 0/5] Follow-up on high-order PCP caching |
| Date: |
| Tue, 15 Feb 2022 14:51:06 +0000 |
| Message-ID: |
| <20220215145111.27082-1-mgorman@techsingularity.net> |
| Cc: |
| Aaron Lu <aaron.lu-AT-intel.com>, Dave Hansen <dave.hansen-AT-linux.intel.com>, Vlastimil Babka <vbabka-AT-suse.cz>, Michal Hocko <mhocko-AT-kernel.org>, Jesper Dangaard Brouer <brouer-AT-redhat.com>, LKML <linux-kernel-AT-vger.kernel.org>, Linux-MM <linux-mm-AT-kvack.org>, Mel Gorman <mgorman-AT-techsingularity.net> |
| Archive-link: |
| Article |
Commit 44042b449872 ("mm/page_alloc: allow high-order pages to be
stored on the per-cpu lists") was primarily aimed at reducing the cost
of SLUB cache refills of high-order pages in two ways. Firstly, zone
lock acquisitions was reduced and secondly, there were fewer buddy list
modifications. This is a follow-up series fixing some issues that became
apparant after merging.
Patch 1 is a functional fix. It's harmless but inefficient.
Patches 2-4 reduce the overhead of bulk freeing of PCP pages. While
the overhead is small, it's cumulative and noticable when truncating
large files. The changelog for patch 4 includes results of a microbench
that deletes large sparse files with data in page cache. Sparse files
were used to eliminate filesystem overhead.
Patch 5 addresses issues with high-order PCP pages being stored on PCP
lists for too long. Pages freed on a CPU potentially may not be quickly
reused and in some cases this can increase cache miss rates. Details are
included in the changelog.
mm/page_alloc.c | 128 ++++++++++++++++++++++++------------------------
1 file changed, 64 insertions(+), 64 deletions(-)
--
2.31.1
