From: Michal Hocko <mhocko@kernel.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Baoquan He <bhe@redhat.com>, David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org,
Wei Yang <richard.weiyang@gmail.com>,
linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
Nathan Fontenot <nfont@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org, Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable()
Date: Thu, 9 Apr 2020 09:59:27 +0200 [thread overview]
Message-ID: <20200409075927.GC18386@dhcp22.suse.cz> (raw)
In-Reply-To: <87sghdjf1y.fsf@mpe.ellerman.id.au>
On Thu 09-04-20 17:26:01, Michael Ellerman wrote:
> David Hildenbrand <david@redhat.com> writes:
>
> > In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory
> > blocks as removable"), the user space interface to compute whether a memory
> > block can be offlined (exposed via
> > /sys/devices/system/memory/memoryX/removable) has effectively been
> > deprecated. We want to remove the leftovers of the kernel implementation.
> >
> > When offlining a memory block (mm/memory_hotplug.c:__offline_pages()),
> > we'll start by:
> > 1. Testing if it contains any holes, and reject if so
> > 2. Testing if pages belong to different zones, and reject if so
> > 3. Isolating the page range, checking if it contains any unmovable pages
> >
> > Using is_mem_section_removable() before trying to offline is not only racy,
> > it can easily result in false positives/negatives. Let's stop manually
> > checking is_mem_section_removable(), and let device_offline() handle it
> > completely instead. We can remove the racy is_mem_section_removable()
> > implementation next.
> >
> > We now take more locks (e.g., memory hotplug lock when offlining and the
> > zone lock when isolating), but maybe we should optimize that
> > implementation instead if this ever becomes a real problem (after all,
> > memory unplug is already an expensive operation). We started using
> > is_mem_section_removable() in commit 51925fb3c5c9 ("powerpc/pseries:
> > Implement memory hotplug remove in the kernel"), with the initial
> > hotremove support of lmbs.
>
> It's also not very pretty in dmesg.
>
> Before:
>
> pseries-hotplug-mem: Attempting to hot-add 10 LMB(s)
> pseries-hotplug-mem: Memory hot-add failed, removing any added LMBs
> dlpar: Could not handle DLPAR request "memory add count 10"
Yeah, there is more output but isn't that useful? Or put it differently
what is the actual problem from having those messages in the kernel log?
From the below you can clearly tell that there are kernel allocations
which prevent hot remove from happening.
If the overall size of the debugging output is a concern then we can
think of a way to reduce it. E.g. once you have a couple of pages
reported then all others from the same block are likely not interesting
much.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-04-09 8:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 13:54 [PATCH v1 0/2] mm/memory_hotplug: remove is_mem_section_removable() David Hildenbrand
2020-04-07 13:54 ` [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable() David Hildenbrand
2020-04-07 13:58 ` Michal Hocko
2020-04-08 2:46 ` Baoquan He
2020-04-09 2:59 ` piliu
2020-04-09 7:26 ` David Hildenbrand
2020-04-09 8:56 ` David Hildenbrand
2020-04-09 14:01 ` piliu
2020-04-09 7:26 ` Michael Ellerman
2020-04-09 7:32 ` David Hildenbrand
2020-04-09 7:59 ` Michal Hocko [this message]
2020-04-09 8:12 ` David Hildenbrand
2020-04-09 8:49 ` Michal Hocko
2020-04-07 13:54 ` [PATCH v1 2/2] mm/memory_hotplug: remove is_mem_section_removable() David Hildenbrand
2020-04-07 14:00 ` Michal Hocko
2020-04-07 21:30 ` Wei Yang
2020-04-08 2:48 ` 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=20200409075927.GC18386@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=nfont@linux.vnet.ibm.com \
--cc=osalvador@suse.de \
--cc=paulus@samba.org \
--cc=richard.weiyang@gmail.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 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).