All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Zhao <yuzhao@google.com>
To: Alex Shi <alex.shi@linux.alibaba.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] mm: use add_page_to_lru_list()/page_lru()/page_off_lru()
Date: Mon, 31 Aug 2020 11:41:54 -0600	[thread overview]
Message-ID: <20200831174154.GA3428138@google.com> (raw)
In-Reply-To: <20200830234404.GA3192017@google.com>

On Sun, Aug 30, 2020 at 05:44:04PM -0600, Yu Zhao wrote:
> On Sun, Aug 30, 2020 at 04:31:38PM +0800, Alex Shi wrote:
> > 
> > 
> > 在 2020/8/30 上午2:12, Yu Zhao 写道:
> > > On Thu, Aug 27, 2020 at 05:42:01PM -0600, Yu Zhao wrote:
> > >> This is a trivial but worth having clean-up patch. There should be
> > >> no side effects except page->lru is temporarily poisoned after it's
> > >> deleted but before it's added to the new list in move_pages_to_lru()
> > >> (which is not a problem).
> > >>
> > >> Signed-off-by: Yu Zhao <yuzhao@google.com>
> > > 
> > > Hi Alex, I just realized your
> > >   [v18,08/32] mm/vmscan: remove unnecessary lruvec adding
> > > at
> > >   https://patchwork.kernel.org/patch/11733123/
> > > also touches move_pages_to_lru(). I agree it's better not to add
> > > a page we are going to free to the list in the first place. The
> > > rest in this patch would be too trivial to be a separate one (on
> > > top of yours).
> > > 
> > > So would you mind taking of the clean-up too in your series? I'll
> > > drop this one then. Thanks.
> 
> Ok, maybe I wasn't clear before. Please see what exactly I'm asking
> you to consider below.
> 
> > >> diff --git a/mm/swap.c b/mm/swap.c
> > >> index 40bf20a75278..2735ecf0f566 100644
> > >> --- a/mm/swap.c
> > >> +++ b/mm/swap.c
> > >> @@ -597,11 +597,9 @@ static void lru_lazyfree_fn(struct page *page, struct lruvec *lruvec,
> > >>  {
> > >>  	if (PageLRU(page) && PageAnon(page) && PageSwapBacked(page) &&
> > >>  	    !PageSwapCache(page) && !PageUnevictable(page)) {
> > >> -		bool active = PageActive(page);
> > >>  		int nr_pages = thp_nr_pages(page);
> > >>  
> > >> -		del_page_from_lru_list(page, lruvec,
> > >> -				       LRU_INACTIVE_ANON + active);
> > >> +		del_page_from_lru_list(page, lruvec, page_lru(page));
> > >>  		ClearPageActive(page);
> > >>  		ClearPageReferenced(page);
> > >>  		/*
> 
> 1) The above has no conflict with your series and therefore can go
> separately. Feel free to include it.
> 
> > >> diff --git a/mm/vmscan.c b/mm/vmscan.c
> > >> index 99e1796eb833..b479ced26cd3 100644
> > >> --- a/mm/vmscan.c
> > >> +++ b/mm/vmscan.c
> > >> @@ -1845,13 +1845,12 @@ static unsigned noinline_for_stack move_pages_to_lru(struct lruvec *lruvec,
> > >>  	int nr_pages, nr_moved = 0;
> > >>  	LIST_HEAD(pages_to_free);
> > >>  	struct page *page;
> > >> -	enum lru_list lru;
> > >>  
> > >>  	while (!list_empty(list)) {
> > >>  		page = lru_to_page(list);
> > >>  		VM_BUG_ON_PAGE(PageLRU(page), page);
> > >> +		list_del(&page->lru);
> > >>  		if (unlikely(!page_evictable(page))) {
> > >> -			list_del(&page->lru);
> > >>  			spin_unlock_irq(&pgdat->lru_lock);
> > >>  			putback_lru_page(page);
> > >>  			spin_lock_irq(&pgdat->lru_lock);
> 
> 2) The above is the same change you've made.
> 
> > >> @@ -1860,16 +1859,10 @@ static unsigned noinline_for_stack move_pages_to_lru(struct lruvec *lruvec,
> > >>  		lruvec = mem_cgroup_page_lruvec(page, pgdat);
> > >>  
> > >>  		SetPageLRU(page);
> > >> -		lru = page_lru(page);
> > >> -
> > >> -		nr_pages = thp_nr_pages(page);
> > >> -		update_lru_size(lruvec, lru, page_zonenum(page), nr_pages);
> > >> -		list_move(&page->lru, &lruvec->lists[lru]);
> > >> +		add_page_to_lru_list(page, lruvec, page_lru(page));
> > >>  
> > >>  		if (put_page_testzero(page)) {
> > >> -			__ClearPageLRU(page);
> > 
> > it's interesting to know the PageLRU left has no bad impact in real life. 
> > it justs seems a path confliction with my that patch. 
> 
> (No, we can't leave PG_lru uncleared. It's done by the page_off_lru()
> right below).

Sorry about this false claim. You are right: we need to keep
__ClearPageLRU() here. page_off_lru() doesn't do it for us.

I'll fix this in v2. Thanks.


      reply	other threads:[~2020-08-31 17:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 23:42 [PATCH 1/2] mm: use add_page_to_lru_list()/page_lru()/page_off_lru() Yu Zhao
2020-08-27 23:42 ` [PATCH 2/2] mm: use self-explanatory macros rather than "2" Yu Zhao
2020-08-29 18:12 ` [PATCH 1/2] mm: use add_page_to_lru_list()/page_lru()/page_off_lru() Yu Zhao
2020-08-30  8:31   ` Alex Shi
2020-08-30 23:44     ` Yu Zhao
2020-08-31 17:41       ` Yu Zhao [this message]

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=20200831174154.GA3428138@google.com \
    --to=yuzhao@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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.