linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Baoquan He <bhe@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Stable tree <stable@vger.kernel.org>
Subject: Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages
Date: Tue, 6 Nov 2018 09:28:26 +0100	[thread overview]
Message-ID: <20181106082826.GC27423@dhcp22.suse.cz> (raw)
In-Reply-To: <20181106002216.GK27491@MiWiFi-R3L-srv>

On Tue 06-11-18 08:22:16, Baoquan He wrote:
> On 11/05/18 at 06:10pm, Michal Hocko wrote:
> > On Mon 05-11-18 22:23:08, Baoquan He wrote:
> > > On 11/05/18 at 01:38pm, Michal Hocko wrote:
> > > > On Mon 05-11-18 18:25:20, Baoquan He wrote:
> > > > > Hi Michal,
> > > > > 
> > > > > On 11/05/18 at 10:28am, Michal Hocko wrote:
> > > > > > 
> > > > > > Or something like this. Ugly as hell, no question about that. I also
> > > > > > have to think about this some more to convince myself this will not
> > > > > > result in an endless loop under some situations.
> > > > > 
> > > > > It failed. Paste the log and patch diff here, please help check if I made
> > > > > any mistake on manual code change. The log is at bottom.
> > > > 
> > > > The retry patch is obviously still racy, it just makes the race window
> > > > slightly smaller and I hoped it would catch most of those races but this
> > > > is obviously not the case.
> > > > 
> > > > I was thinking about your MIGRATE_MOVABLE check some more and I still do
> > > > not like it much, we just change migrate type at many places and I have
> > > > hard time to actually see this is always safe wrt. to what we need here.
> > > > 
> > > > We should be able to restore the zone type check though. The
> > > > primary problem fixed by 15c30bc09085 ("mm, memory_hotplug: make
> > > > has_unmovable_pages more robust") was that early allocations made it to
> > > > the zone_movable range. If we add the check _after_ the PageReserved()
> > > > check then we should be able to rule all bootmem allocation out.
> > > > 
> > > > So what about the following (on top of the previous patch which makes
> > > > sense on its own I believe).
> > > 
> > > Yes, I think this looks very reasonable and should be robust.
> > > 
> > > Have tested it, hot removing 4 hotpluggable nodes continusously
> > > succeeds, and then hot adding them back, still works well.
> > > 
> > > So please feel free to add my Tested-by or Acked-by.
> > > 
> > > Tested-by: Baoquan He <bhe@redhat.com>
> > > or
> > > Acked-by: Baoquan He <bhe@redhat.com>
> > 
> > Thanks for retesting! Does this apply to both patches?
> 
> Sorry, don't get it. I just applied this on top of linus's tree and
> tested. Do you mean applying it on top of previous code change?

Yes. While the first patch will obviously not help for movable zone
because the movable check will override any later check it
seems still useful to reduce false positives on normal zones.

Or do you think this is not worth it?

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-11-06  8:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01  9:10 Memory hotplug failed to offline on bare metal system of multiple nodes Baoquan He
2018-11-01  9:22 ` Michal Hocko
2018-11-01  9:42   ` Baoquan He
2018-11-01  9:58     ` Michal Hocko
2018-11-02 15:55 ` [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages Michal Hocko
2018-11-05  0:20   ` Baoquan He
2018-11-05  9:14     ` Michal Hocko
2018-11-05  9:26       ` Baoquan He
2018-11-05  9:35         ` Michal Hocko
2018-11-05  9:28       ` Michal Hocko
2018-11-05  9:45         ` Baoquan He
2018-11-05 10:25         ` Baoquan He
2018-11-05 12:38           ` Michal Hocko
2018-11-05 14:23             ` Baoquan He
2018-11-05 17:10               ` Michal Hocko
2018-11-06  0:22                 ` Baoquan He
2018-11-06  8:28                   ` Michal Hocko [this message]
2018-11-06  9:16                     ` Baoquan He
2018-11-06  9:36                       ` Baoquan He
2018-11-06  9:51                       ` Michal Hocko
2018-11-06 10:00                         ` Baoquan He

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=20181106082826.GC27423@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stable@vger.kernel.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 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).