All of lore.kernel.org
 help / color / mirror / Atom feed
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 09:14:18 +0200	[thread overview]
Message-ID: <20190405071418.GN12864@dhcp22.suse.cz> (raw)
In-Reply-To: <5f735328-3451-ebd7-048e-e83e74e2c622@redhat.com>

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

> 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

This is an internal API so we are not carving anything into the stone.
So can we simply start with what we have and go from there? I am getting
felling that this discussion just makes the whole thing more muddy.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2019-04-05  7:33 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 [this message]
2019-04-05  8:05           ` David Hildenbrand
2019-04-05 10:30             ` Michal Hocko
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=20190405071418.GN12864@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.