From: Mel Gorman <mgorman@techsingularity.net>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Oscar Salvador <osalvador@suse.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
David Hildenbrand <david@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH] mm/memory_hotplug: Make unpopulated zones PCP structures unreachable during hot remove
Date: Fri, 9 Apr 2021 14:42:21 +0100 [thread overview]
Message-ID: <20210409134221.GO3697@techsingularity.net> (raw)
In-Reply-To: <YHBNDEAw1OqIWwb5@dhcp22.suse.cz>
On Fri, Apr 09, 2021 at 02:48:12PM +0200, Michal Hocko wrote:
> On Fri 09-04-21 14:42:58, Michal Hocko wrote:
> > On Fri 09-04-21 13:09:57, Mel Gorman wrote:
> > > zone_pcp_reset allegedly protects against a race with drain_pages
> > > using local_irq_save but this is bogus. local_irq_save only operates
> > > on the local CPU. If memory hotplug is running on CPU A and drain_pages
> > > is running on CPU B, disabling IRQs on CPU A does not affect CPU B and
> > > offers no protection.
> >
> > Yes, the synchronization aspect is bogus indeed.
> >
> > > This patch reorders memory hotremove such that the PCP structures
> > > relevant to the zone are no longer reachable by the time the structures
> > > are freed. With this reordering, no protection is required to prevent
> > > a use-after-free and the IRQs can be left enabled. zone_pcp_reset is
> > > renamed to zone_pcp_destroy to make it clear that the per-cpu structures
> > > are deleted when the function returns.
> >
> > Wouldn't it be much easier to simply not destroy/reset pcp of an empty
> > zone at all? The whole point of this exercise seems to be described in
> > 340175b7d14d5. setup_zone_pageset can check for an already allocated pcp
> > and simply reinitialize it.
>
> I meant this
>
It might be simplier but if the intention is to free as much memory
as possible during hot-remove, it seems wasteful to leave the per-cpu
structures behind if we do not have to. If a problem with my patch can
be spotted then I'm happy to go with an alternative fix but there are
two minor issues with your proposed fix.
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e6a602e82860..b0fdda77e570 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6496,7 +6496,13 @@ void __meminit setup_zone_pageset(struct zone *zone)
> struct per_cpu_pageset *p;
> int cpu;
>
> - zone->pageset = alloc_percpu(struct per_cpu_pageset);
> + /*
> + * zone could have gone completely offline during memory hotplug
> + * when the pgdat is left behind for simplicity. On a next onlining
> + * we do not need to reallocate pcp state.
> + */
> + if (!zone->pageset)
> + zone->pageset = alloc_percpu(struct per_cpu_pageset);
Should be "if (zone->pageset != &boot_pageset)" ?
> for_each_possible_cpu(cpu) {
> p = per_cpu_ptr(zone->pageset, cpu);
> pageset_init(p);
> @@ -8803,25 +8809,6 @@ void zone_pcp_enable(struct zone *zone)
> mutex_unlock(&pcp_batch_high_lock);
> }
>
> -void zone_pcp_reset(struct zone *zone)
> -{
> - unsigned long flags;
> - int cpu;
> - struct per_cpu_pageset *pset;
> -
> - /* avoid races with drain_pages() */
> - local_irq_save(flags);
> - if (zone->pageset != &boot_pageset) {
> - for_each_online_cpu(cpu) {
> - pset = per_cpu_ptr(zone->pageset, cpu);
> - drain_zonestat(zone, pset);
> - }
> - free_percpu(zone->pageset);
> - zone->pageset = &boot_pageset;
> - }
> - local_irq_restore(flags);
> -}
> -
zone_pcp_reset still needs to exist to drain the remaining vmstats or
it'll break 5a883813845a ("memory-hotplug: fix zone stat
mismatch").
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2021-04-09 13:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 12:09 [PATCH] mm/memory_hotplug: Make unpopulated zones PCP structures unreachable during hot remove Mel Gorman
2021-04-09 12:42 ` Michal Hocko
2021-04-09 12:48 ` Michal Hocko
2021-04-09 13:42 ` Mel Gorman [this message]
2021-04-09 14:37 ` Michal Hocko
2021-04-09 15:12 ` Mel Gorman
2021-04-09 19:05 ` David Hildenbrand
2021-04-10 7:25 ` Michal Hocko
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=20210409134221.GO3697@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.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.