[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7622d74e-5884-4ee5-382d-78d6476db18a@linux.alibaba.com>
Date: Tue, 4 Aug 2020 16:36:51 +0800
From: Alex Shi <alex.shi@...ux.alibaba.com>
To: akpm@...ux-foundation.org, mgorman@...hsingularity.net,
tj@...nel.org, hughd@...gle.com, khlebnikov@...dex-team.ru,
daniel.m.jordan@...cle.com, yang.shi@...ux.alibaba.com,
willy@...radead.org, hannes@...xchg.org, lkp@...el.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, shakeelb@...gle.com,
iamjoonsoo.kim@....com, richard.weiyang@...il.com,
kirill@...temov.name, alexander.duyck@...il.com,
rong.a.chen@...el.com, Vladimir Davydov <vdavydov.dev@...il.com>,
Michal Hocko <mhocko@...nel.org>
Subject: Re: [PATCH v17 00/21] per memcg lru lock
>From e2918c8fa741442255a2f12659f95dae94fdfe5d Mon Sep 17 00:00:00 2001
From: Alex Shi <alex.shi@...ux.alibaba.com>
Date: Sat, 1 Aug 2020 22:49:31 +0800
Subject: [PATCH 3/3] mm/swap.c: optimizing __pagevec_lru_add lru_lock
The current relock will unlock/lock lru_lock with every time lruvec
changes, so it would cause frequency relock if 2 memcgs are reading file
simultaneously.
This patch will record the involved lru_lock and only hold them once in
above scenario. That could reduce the lock contention.
Using per cpu data intead of local stack data to avoid repeatly
INIT_LIST_HEAD action.
[lkp@...el.com: found a build issue in the original patch, thanks]
Suggested-by: Konstantin Khlebnikov <koct9i@...il.com>
Signed-off-by: Alex Shi <alex.shi@...ux.alibaba.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org
---
mm/swap.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 51 insertions(+), 6 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index d88a6c650a7c..e227fec6983c 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -72,6 +72,27 @@ static DEFINE_PER_CPU(struct lru_pvecs, lru_pvecs) = {
.lock = INIT_LOCAL_LOCK(lock),
};
+struct pvlvs {
+ struct list_head lists[PAGEVEC_SIZE];
+ struct lruvec *vecs[PAGEVEC_SIZE];
+};
+static DEFINE_PER_CPU(struct pvlvs, pvlvs);
+
+static int __init pvlvs_init(void) {
+ int i, cpu;
+ struct pvlvs *pvecs;
+
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ if (!cpu_possible(cpu))
+ continue;
+ pvecs = per_cpu_ptr(&pvlvs, cpu);
+ for (i = 0; i < PAGEVEC_SIZE; i++)
+ INIT_LIST_HEAD(&pvecs->lists[i]);
+ }
+ return 0;
+}
+subsys_initcall(pvlvs_init);
+
/*
* This path almost never happens for VM activity - pages are normally
* freed via pagevecs. But it gets used by networking.
@@ -963,18 +984,42 @@ static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec)
*/
void __pagevec_lru_add(struct pagevec *pvec)
{
- int i;
+ int i, j, total = 0;
struct lruvec *lruvec = NULL;
unsigned long flags = 0;
+ struct page *page;
+ struct pvlvs *lvs = this_cpu_ptr(&pvlvs);
+ /* Sort the same lruvec pages on a list. */
for (i = 0; i < pagevec_count(pvec); i++) {
- struct page *page = pvec->pages[i];
+ page = pvec->pages[i];
+ lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page));
+
+ /* Try to find a same lruvec */
+ for (j = 0; j <= total; j++)
+ if (lruvec == lvs->vecs[j])
+ break;
+ /* A new lruvec */
+ if (j > total) {
+ lvs->vecs[total] = lruvec;
+ j = total;
+ total++;
+ }
- lruvec = relock_page_lruvec_irqsave(page, lruvec, &flags);
- __pagevec_lru_add_fn(page, lruvec);
+ list_add(&page->lru, &lvs->lists[j]);
}
- if (lruvec)
- unlock_page_lruvec_irqrestore(lruvec, flags);
+
+ for (i = 0; i < total; i++) {
+ spin_lock_irqsave(&lvs->vecs[i]->lru_lock, flags);
+ while (!list_empty(&lvs->lists[i])) {
+ page = lru_to_page(&lvs->lists[i]);
+ list_del(&page->lru);
+ __pagevec_lru_add_fn(page, lvs->vecs[i]);
+ }
+ spin_unlock_irqrestore(&lvs->vecs[i]->lru_lock, flags);
+ lvs->vecs[i] = NULL;
+ }
+
release_pages(pvec->pages, pvec->nr);
pagevec_reinit(pvec);
}
--
1.8.3.1
Powered by blists - more mailing lists