All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Zhao <yuzhao@google.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alex Shi <alex.shi@linux.alibaba.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Roman Gushchin <guro@fb.com>, Shakeel Butt <shakeelb@google.com>,
	Chris Down <chris@chrisdown.name>,
	Yafang Shao <laoar.shao@gmail.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Huang Ying <ying.huang@intel.com>,
	Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Konstantin Khlebnikov <koct9i@gmail.com>,
	Minchan Kim <minchan@kernel.org>,
	Jaewon Kim <jaewon31.kim@samsung.com>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/13] mm: use page_off_lru()
Date: Fri, 18 Sep 2020 04:27:13 -0600	[thread overview]
Message-ID: <20200918102713.GB1004594@google.com> (raw)
In-Reply-To: <20200918073700.GE28827@dhcp22.suse.cz>

On Fri, Sep 18, 2020 at 09:37:00AM +0200, Michal Hocko wrote:
> On Thu 17-09-20 21:00:40, Yu Zhao wrote:
> > This patch replaces the only open-coded __ClearPageActive() with
> > page_off_lru(). There is no open-coded __ClearPageUnevictable()s.
> > 
> > Before this patch, we have:
> > 	__ClearPageActive()
> > 	add_page_to_lru_list()
> > 
> > After this patch, we have:
> > 	page_off_lru()
> > 		if PageUnevictable()
> > 			__ClearPageUnevictable()
> > 		else if PageActive()
> > 			__ClearPageActive()
> > 	add_page_to_lru_list()
> > 
> > Checking PageUnevictable() shouldn't be a problem because these two
> > flags are mutually exclusive. Leaking either will trigger bad_page().
> 
> I am sorry but the changelog is really hard to grasp. What are you
> trying to achieve, why and why it is safe. This should be a general
> outline for any patch. I have already commented on the previous patch
> and asked you for the explanation why removing __ClearPageActive from
> this path is desirable and safe. I have specifically asked to clarify
> the compound page situation as that is using its oen destructor in the
> freeing path and that might result in page_off_lru to be not called.

Haven't I explained we are NOT removing __ClearPageActive()? Is my
notion of the code structure above confusing you? Or 'open-coded'
could mean different things?

And I have asked this before: why does 'the compound page situation'
even matter here? Perhaps if you could give a concrete example related
to the code change and help me understand your concern?

> > Signed-off-by: Yu Zhao <yuzhao@google.com>
> > ---
> >  mm/vmscan.c | 6 +-----
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 503fc5e1fe32..f257d2f61574 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1845,7 +1845,6 @@ 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);
> > @@ -1860,14 +1859,11 @@ 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);
> > -
> >  		add_page_to_lru_list(page, lruvec, lru);
> >  
> >  		if (put_page_testzero(page)) {
> >  			__ClearPageLRU(page);
> > -			__ClearPageActive(page);
> > -			del_page_from_lru_list(page, lruvec, lru);
> > +			del_page_from_lru_list(page, lruvec, page_off_lru(page));
> >  
> >  			if (unlikely(PageCompound(page))) {
> >  				spin_unlock_irq(&pgdat->lru_lock);
> > -- 
> > 2.28.0.681.g6f77f65b4e-goog
> 
> -- 
> Michal Hocko
> SUSE Labs

  reply	other threads:[~2020-09-18 10:27 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18  3:00 [PATCH 00/13] mm: clean up some lru related pieces Yu Zhao
2020-09-18  3:00 ` [PATCH 02/13] mm: use page_off_lru() Yu Zhao
     [not found]   ` <20200918030051.650890-3-yuzhao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-09-18  7:37     ` Michal Hocko
2020-09-18  7:37       ` Michal Hocko
2020-09-18 10:27       ` Yu Zhao [this message]
2020-09-18 11:09         ` Michal Hocko
     [not found]           ` <20200918110914.GK28827-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-09-18 18:53             ` Yu Zhao
2020-09-18 18:53               ` Yu Zhao
     [not found]               ` <20200918185358.GA1095986-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-09-21 11:16                 ` Michal Hocko
2020-09-21 11:16                   ` Michal Hocko
     [not found]         ` <20200918102713.GB1004594-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-09-18 11:24           ` Michal Hocko
2020-09-18 11:24             ` Michal Hocko
2020-09-18  3:00 ` [PATCH 03/13] mm: move __ClearPageLRU() into page_off_lru() Yu Zhao
     [not found]   ` <20200918030051.650890-4-yuzhao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-09-18  7:38     ` Michal Hocko
2020-09-18  7:38       ` Michal Hocko
2020-09-18  3:00 ` [PATCH 04/13] mm: shuffle lru list addition and deletion functions Yu Zhao
2020-09-18  3:00 ` [PATCH 05/13] mm: don't pass enum lru_list to lru list addition functions Yu Zhao
2020-09-18  3:00 ` [PATCH 08/13] mm: rename page_off_lru() to __clear_page_lru_flags() Yu Zhao
     [not found] ` <20200918030051.650890-1-yuzhao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-09-18  3:00   ` [PATCH 01/13] mm: use add_page_to_lru_list() Yu Zhao
2020-09-18  3:00     ` Yu Zhao
     [not found]     ` <20200918030051.650890-2-yuzhao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-09-18  7:32       ` Michal Hocko
2020-09-18  7:32         ` Michal Hocko
2020-09-18 10:05         ` Yu Zhao
2020-09-18  3:00   ` [PATCH 06/13] mm: don't pass enum lru_list to trace_mm_lru_insertion() Yu Zhao
2020-09-18  3:00     ` Yu Zhao
2020-09-18  3:00   ` [PATCH 07/13] mm: don't pass enum lru_list to del_page_from_lru_list() Yu Zhao
2020-09-18  3:00     ` Yu Zhao
2020-09-18  3:00   ` [PATCH 09/13] mm: inline page_lru_base_type() Yu Zhao
2020-09-18  3:00     ` Yu Zhao
2020-09-18  3:00   ` [PATCH 10/13] mm: VM_BUG_ON lru page flags Yu Zhao
2020-09-18  3:00     ` Yu Zhao
2020-09-18  3:00   ` [PATCH 11/13] mm: inline __update_lru_size() Yu Zhao
2020-09-18  3:00     ` Yu Zhao
2020-09-18  3:00   ` [PATCH 12/13] mm: make lruvec_lru_size() static Yu Zhao
2020-09-18  3:00     ` Yu Zhao
2020-09-18  3:00   ` [PATCH 13/13] mm: enlarge the int parameter of update_lru_size() Yu Zhao
2020-09-18  3:00     ` Yu Zhao
2020-09-18  7:45   ` [PATCH 00/13] mm: clean up some lru related pieces Michal Hocko
2020-09-18  7:45     ` Michal Hocko
     [not found]     ` <20200918074549.GG28827-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-09-18  9:36       ` Yu Zhao
2020-09-18  9:36         ` Yu Zhao
2020-09-18 20:46   ` Hugh Dickins
2020-09-18 20:46     ` Hugh Dickins
     [not found]     ` <alpine.LSU.2.11.2009181317350.11298-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2020-09-18 21:01       ` Yu Zhao
2020-09-18 21:01         ` Yu Zhao
     [not found]         ` <20200918210126.GA1118730-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-09-18 21:19           ` Hugh Dickins
2020-09-18 21:19             ` Hugh Dickins
     [not found]             ` <alpine.LSU.2.11.2009181406410.11531-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2020-09-19  0:31               ` Alex Shi
2020-09-19  0:31                 ` Alex Shi
2020-10-13  2:30               ` Hugh Dickins
2020-10-13  2:30                 ` Hugh Dickins

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=20200918102713.GB1004594@google.com \
    --to=yuzhao@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linux.alibaba.com \
    --cc=cgroups@vger.kernel.org \
    --cc=chris@chrisdown.name \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=jaewon31.kim@samsung.com \
    --cc=koct9i@gmail.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=shakeelb@google.com \
    --cc=vbabka@suse.cz \
    --cc=vdavydov.dev@gmail.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 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.