[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190405103053.GO12864@dhcp22.suse.cz>
Date: Fri, 5 Apr 2019 12:30:53 +0200
From: Michal Hocko <mhocko@...nel.org>
To: David Hildenbrand <david@...hat.com>
Cc: Oscar Salvador <osalvador@...e.de>, akpm@...ux-foundation.org,
dan.j.williams@...el.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 2/2] mm, memory_hotplug: provide a more generic
restrictions for memory hotplug
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
Powered by blists - more mailing lists