From: Michal Hocko <mhocko@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>,
akpm@linux-foundation.org, dan.j.williams@intel.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] mm, memory_hotplug: provide a more generic restrictions for memory hotplug
Date: Fri, 5 Apr 2019 12:30:53 +0200 [thread overview]
Message-ID: <20190405103053.GO12864@dhcp22.suse.cz> (raw)
In-Reply-To: <a4230528-dc7e-e17c-c363-e3da7961dbf1@redhat.com>
On Fri 05-04-19 10:05:09, David Hildenbrand wrote:
> On 05.04.19 09:14, Michal Hocko wrote:
> > On Thu 04-04-19 20:27:41, David Hildenbrand wrote:
> >> On 04.04.19 20:01, Oscar Salvador wrote:
> > [...]
> >>> But I am not really convinced by MHP_SYSTEM_RAM name, and I think we should stick
> >>> with MHP_MEMBLOCK_API because it represents __what__ is that flag about and its
> >>> function, e.g: create memory block devices.
> >
> > Exactly
>
> Fine with me for keeping what Oscar has.
>
> >
> >> This nicely aligns with the sub-section memory add support discussion.
> >>
> >> MHP_MEMBLOCK_API immediately implies that
> >>
> >> - memory is used as system ram. Memory can be onlined/offlined. Markers
> >> at sections indicate if the section is online/offline.
> >
> > No there is no implication like that. It means only that the onlined
> > memory has a sysfs interface. Nothing more, nothing less
>
> As soon as there is a online/offline interface, you *can* (and user
> space usually *will*) online that memory. Onlining/offlining is only
> defined for memory to be added to the buddy - memory to be used as
> "system ram". Doing it for random device memory will not work / result
> in undefined behavior.
No, not really. We really do not care where the memory comes from. Is it
RAM, NVDIMM, $FOO_BAR_OF_A_FUTURE_BUZZ. We only do care that the memory
can be onlined - user triggered associated with a zone. The memory even
doesn't have to go to the page allocator.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-04-05 10:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 12:59 [PATCH 0/2] Preparing memhotplug for allocating memmap from hot-added range Oscar Salvador
2019-04-04 12:59 ` [PATCH 1/2] mm, memory_hotplug: cleanup memory offline path Oscar Salvador
2019-04-04 13:18 ` David Hildenbrand
2019-04-04 13:25 ` Oscar Salvador
2019-04-04 14:47 ` David Hildenbrand
2019-04-04 15:40 ` Oscar Salvador
2019-04-04 16:50 ` David Hildenbrand
2019-04-04 12:59 ` [PATCH 2/2] mm, memory_hotplug: provide a more generic restrictions for memory hotplug Oscar Salvador
2019-04-04 14:57 ` David Hildenbrand
2019-04-04 15:02 ` David Hildenbrand
2019-04-04 18:01 ` Oscar Salvador
2019-04-04 18:27 ` David Hildenbrand
2019-04-05 7:14 ` Michal Hocko
2019-04-05 8:05 ` David Hildenbrand
2019-04-05 10:30 ` Michal Hocko [this message]
2019-04-05 10:56 ` David Hildenbrand
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=20190405103053.GO12864@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
/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.