From: Mel Gorman <mgorman@techsingularity.net>
To: David Hildenbrand <david@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Oscar Salvador <osalvador@suse.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
Alexander Duyck <alexanderduyck@fb.com>,
Minchan Kim <minchan@kernel.org>, Michal Hocko <mhocko@suse.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 resend] mm/memory_hotplug: Make unpopulated zones PCP structures unreachable during hot remove
Date: Mon, 12 Apr 2021 16:27:37 +0100 [thread overview]
Message-ID: <20210412152737.GB3697@techsingularity.net> (raw)
In-Reply-To: <a0d73ce0-b2bd-1928-539d-39cb9da9bf1f@redhat.com>
On Mon, Apr 12, 2021 at 04:12:11PM +0200, David Hildenbrand wrote:
> > After v1 of the patch, the race was reduced to the point between the
> > zone watermark check and the rmqueue_pcplist but yes, it still existed.
> > Closing it completely was either complex or expensive. Setting
> > zone->pageset = &boot_pageset before the free would shrink the race
> > further but that still leaves a potential memory ordering issue.
> >
> > While fixable, it's either complex, expensive or both so yes, just leaving
> > the pageset structures in place would be much more straight-forward
> > assuming the structures were not allocated in the zone that is being
> > hot-removed. As things stand, I had trouble even testing zone hot-remove
> > as there was always a few pages left behind and I did not chase down
> > why.
>
> Can you elaborate? I can reliably trigger zone present pages going to 0 by
> just hotplugging a DIMM, onlining the memory block devices to the MOVABLE
> zone, followed by offlining the memory block again.
>
For the machine I was testing on, I tried offlining all memory within
a zone on a NUMA machine. Even if I used movable_zone to create a zone
or numa=fake to create multiple fake nodes and zones, there was always
either reserved or pinned pages preventing the full zone being removed.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2021-04-12 15:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 12:08 [PATCH v2 resend] mm/memory_hotplug: Make unpopulated zones PCP structures unreachable during hot remove Mel Gorman
2021-04-12 12:12 ` David Hildenbrand
2021-04-12 12:40 ` Vlastimil Babka
2021-04-12 14:08 ` Mel Gorman
2021-04-12 14:12 ` David Hildenbrand
2021-04-12 15:27 ` Mel Gorman [this message]
2021-04-12 16:02 ` David Hildenbrand
2021-04-13 9:36 ` Vlastimil Babka
2021-04-13 9:49 ` Mel Gorman
2021-04-13 10:16 ` Michal Hocko
2021-04-13 6:44 ` Michal Hocko
2021-04-13 6:40 ` Michal Hocko
2021-04-14 7:18 ` Oscar Salvador
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=20210412152737.GB3697@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=alexanderduyck@fb.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=mst@redhat.com \
--cc=osalvador@suse.de \
--cc=vbabka@suse.cz \
/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.