From: Linus Torvalds <torvalds@linux-foundation.org>
To: huang ying <huang.ying.caritas@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Huang Ying <ying.huang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Xu <peterx@redhat.com>, Hugh Dickins <hughd@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@surriel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Michal Hocko <mhocko@kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
Tim Chen <tim.c.chen@intel.com>
Subject: Re: [PATCH] mm: Free unused swap cache page in write protection fault handler
Date: Wed, 13 Jan 2021 13:09:31 -0800 [thread overview]
Message-ID: <CAHk-=wh3nL28QfkKV6gpVGjh5iPjoEZtEQYPDvwPgscm-yMAfA@mail.gmail.com> (raw)
In-Reply-To: <CAC=cRTNMN5Pmz2PC8p3N2-uJkqLUCW95wr=VWTZmodoECmj6nQ@mail.gmail.com>
On Tue, Jan 12, 2021 at 9:24 PM huang ying <huang.ying.caritas@gmail.com> wrote:
> >
> > Couldn't we just move it to the tail of the LRU list so it's reclaimed
> > first? Or is locking going to be a problem here?
>
> Yes. That's a way to reduce the disturbance to the page reclaiming.
> For LRU lock contention, is it sufficient to use another pagevec?
I wonder if this is really worth it. I'd like to see numbers.
Because in probably 99%+ of all cases, that LRU dance is only going to
hurt and add extra locking overhead and dirty caches.
So I'd like to see some numbers that it actually helps measurably in
whatever paging-heavy case...
Linus
next prev parent reply other threads:[~2021-01-13 21:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-13 2:42 [PATCH] mm: Free unused swap cache page in write protection fault handler Huang Ying
2021-01-13 2:47 ` Linus Torvalds
2021-01-13 3:08 ` huang ying
2021-01-13 3:11 ` Matthew Wilcox
2021-01-13 5:24 ` huang ying
2021-01-13 21:09 ` Linus Torvalds [this message]
2021-01-15 8:47 ` Huang, Ying
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='CAHk-=wh3nL28QfkKV6gpVGjh5iPjoEZtEQYPDvwPgscm-yMAfA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=huang.ying.caritas@gmail.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=peterx@redhat.com \
--cc=riel@surriel.com \
--cc=tim.c.chen@intel.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).