From: Alex Shi <alex.shi@linux.alibaba.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
Hugh Dickins <hughd@google.com>, Yu Zhao <yuzhao@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH next] mm/swap.c: reduce lock contention in lru_cache_add
Date: Mon, 23 Nov 2020 12:46:36 +0800 [thread overview]
Message-ID: <ae6509ef-66f5-eabe-2f9c-b28871b68db0@linux.alibaba.com> (raw)
In-Reply-To: <20201120151948.c3f4175ed18ed74e46760b87@linux-foundation.org>
在 2020/11/21 上午7:19, Andrew Morton 写道:
> On Fri, 20 Nov 2020 16:27:27 +0800 Alex Shi <alex.shi@linux.alibaba.com> wrote:
>
>> The current relock logical will change lru_lock when found a new
>> lruvec, so if 2 memcgs are reading file or alloc page at same time,
>> they could hold the lru_lock alternately, and wait for each other for
>> fairness attribute of ticket spin lock.
>>
>> This patch will sort that all lru_locks and only hold them once in
>> above scenario. That could reduce fairness waiting for lock reget.
>> Than, vm-scalability/case-lru-file-readtwice could get ~5% performance
>> gain on my 2P*20core*HT machine.
>
> But what happens when all or most of the pages belong to the same
> lruvec? This sounds like the common case - won't it suffer?
>
Hi Andrew,
My testing show no regression on this situation, like original centos7,
The most spending time is on lru_lock for lru sensitive case.
Thanks
Alex
next prev parent reply other threads:[~2020-11-23 4:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 8:27 [PATCH next] mm/swap.c: reduce lock contention in lru_cache_add Alex Shi
2020-11-20 8:27 ` Alex Shi
2020-11-20 23:19 ` Andrew Morton
2020-11-23 4:46 ` Alex Shi [this message]
2020-11-25 15:38 ` Vlastimil Babka
2020-11-26 3:12 ` Alex Shi
2020-11-26 11:05 ` Vlastimil Babka
2020-11-26 4:52 ` Yu Zhao
2020-11-26 6:39 ` Alex Shi
2020-11-26 7:24 ` Yu Zhao
2020-11-26 8:09 ` Alex Shi
2020-11-26 11:22 ` Vlastimil Babka
2020-11-26 15:44 ` Vlastimil Babka
2020-11-26 15:55 ` Matthew Wilcox
2020-11-27 3:14 ` Alex Shi
2020-12-01 8:02 ` [PATCH 1/3] mm/swap.c: pre-sort pages in pagevec for pagevec_lru_move_fn Alex Shi
2020-12-01 8:02 ` [PATCH 2/3] mm/swap.c: bail out early for no memcg and no numa Alex Shi
2020-12-01 8:02 ` [PATCH 3/3] mm/swap.c: extend the usage to pagevec_lru_add Alex Shi
2020-12-01 8:10 ` [PATCH 1/3] mm/swap.c: pre-sort pages in pagevec for pagevec_lru_move_fn Michal Hocko
2020-12-01 8:20 ` Alex Shi
2020-12-25 9:59 ` [RFC PATCH 0/4] pre sort pages on lruvec in pagevec Alex Shi
2020-12-25 9:59 ` [RFC PATCH 1/4] mm/swap.c: pre-sort pages in pagevec for pagevec_lru_move_fn Alex Shi
2020-12-25 9:59 ` [RFC PATCH 2/4] mm/swap.c: bail out early for no memcg and no numa Alex Shi
2020-12-25 9:59 ` [RFC PATCH 3/4] mm/swap.c: extend the usage to pagevec_lru_add Alex Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ae6509ef-66f5-eabe-2f9c-b28871b68db0@linux.alibaba.com \
--to=alex.shi@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.