All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Rashmica Gupta <rashmica.g@gmail.com>,
	Oscar Salvador <osalvador@suse.de>
Cc: akpm@linux-foundation.org, mhocko@suse.com,
	dan.j.williams@intel.com, pasha.tatashin@soleen.com,
	Jonathan.Cameron@huawei.com, anshuman.khandual@arm.com,
	vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/5] Allocate memmap from hotadded memory
Date: Wed, 31 Jul 2019 11:39:18 +0200	[thread overview]
Message-ID: <5454a6b8-4abc-0922-63a4-a7c0e9d44fcf@redhat.com> (raw)
In-Reply-To: <7c49e493510ce04371d8d6cd6c436c347b1f8469.camel@gmail.com>

On 31.07.19 04:21, Rashmica Gupta wrote:
> On Mon, 2019-07-29 at 10:06 +0200, David Hildenbrand wrote:
>>>> Of course, other interfaces might make sense.
>>>>
>>>> You can then start using these memory blocks and hinder them from
>>>> getting onlined (as a safety net) via memory notifiers.
>>>>
>>>> That would at least avoid you having to call
>>>> add_memory/remove_memory/offline_pages/device_online/modifying
>>>> memblock
>>>> states manually.
>>>
>>> I see what you're saying and that definitely sounds safer.
>>>
>>> We would still need to call remove_memory and add_memory from
>>> memtrace
>>> as
>>> just offlining memory doesn't remove it from the linear page tables
>>> (if 
>>> it's still in the page tables then hardware can prefetch it and if
>>> hardware tracing is using it then the box checkstops).
>>
>> That prefetching part is interesting (and nasty as well). If we could
>> at
>> least get rid of the manual onlining/offlining, I would be able to
>> sleep
>> better at night ;) One step at a time.
>>
> 
> What are your thoughts on adding remove to state_store in
> drivers/base/memory.c? And an accompanying add? So then userspace could
> do "echo remove > memory34/state"? 

I consider such an interface dangerous (removing random memory you don't
own, especially in the context of Oscars work some blocks would suddenly
not be removable again) and only of limited used. The requirement of
memtrace is really special, and it only works somewhat reliably with
boot memory.

FWIW, we do have a "probe" interface on some architectures but decided
that a "remove" interface belongs into a debug/test kernel module. The
memory block device API is already messed up enough (e.g., "removable"
property which doesn't indicate at all if memory can be removed, only if
it could be offlined) - we decided to keep changes at a minimum for now
- rather clean up than add new stuff.

> Then most of the memtrace code could be moved to a userspace tool. The
> only bit that we would need to keep in the kernel is setting up debugfs
> files in memtrace_init_debugfs.

The nice thing is, with remove_memory() you will now get an error in
case all memory blocks are not offline yet. So it only boils down to
calling add_memory()/remove_memory() without even checking the state of
the blocks. (only nids have to be handled manually correctly)

-- 

Thanks,

David / dhildenb

      reply	other threads:[~2019-07-31  9:39 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25  7:52 [PATCH v2 0/5] Allocate memmap from hotadded memory Oscar Salvador
2019-06-25  7:52 ` [PATCH v2 1/5] drivers/base/memory: Remove unneeded check in remove_memory_block_devices Oscar Salvador
2019-06-25  8:01   ` David Hildenbrand
2019-06-25  8:03     ` David Hildenbrand
2019-06-25  8:09       ` Oscar Salvador
2019-06-25  8:27         ` David Hildenbrand
2019-06-25  7:52 ` [PATCH v2 2/5] mm,memory_hotplug: Introduce MHP_VMEMMAP_FLAGS Oscar Salvador
2019-06-25  8:31   ` David Hildenbrand
2019-07-24 20:11   ` Dan Williams
2019-07-24 20:11     ` Dan Williams
2019-07-24 21:36     ` osalvador
2019-07-25  9:27     ` Oscar Salvador
2019-07-25  9:30       ` David Hildenbrand
2019-07-25  9:40         ` Oscar Salvador
2019-07-25 10:04           ` David Hildenbrand
2019-07-25 10:13             ` Oscar Salvador
2019-07-25 10:15               ` David Hildenbrand
2019-06-25  7:52 ` [PATCH v2 3/5] mm,memory_hotplug: Introduce Vmemmap page helpers Oscar Salvador
2019-06-25 10:28   ` David Hildenbrand
2019-06-26  9:48     ` Oscar Salvador
2019-06-25  7:52 ` [PATCH v2 4/5] mm,memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap Oscar Salvador
2019-06-25  8:49   ` David Hildenbrand
2019-06-26  8:13     ` Oscar Salvador
2019-06-26  8:15       ` David Hildenbrand
2019-06-26  8:17   ` Anshuman Khandual
2019-06-26  8:28     ` Oscar Salvador
2019-07-24 21:49   ` Dan Williams
2019-07-24 21:49     ` Dan Williams
2019-06-25  7:52 ` [PATCH v2 5/5] mm,memory_hotplug: Allow userspace to enable/disable vmemmap Oscar Salvador
2019-06-25  8:25 ` [PATCH v2 0/5] Allocate memmap from hotadded memory David Hildenbrand
2019-06-25  8:33   ` David Hildenbrand
2019-06-26  8:03   ` Oscar Salvador
2019-06-26  8:11     ` David Hildenbrand
2019-06-26  8:15       ` Oscar Salvador
2019-06-26  8:27         ` Oscar Salvador
2019-06-26  8:37           ` David Hildenbrand
2019-06-26  8:28         ` David Hildenbrand
2019-07-02  6:42           ` Rashmica Gupta
2019-07-02  6:42             ` Rashmica Gupta
2019-07-02  7:48             ` Oscar Salvador
2019-07-02  8:52               ` Rashmica Gupta
2019-07-10  1:14                 ` Rashmica Gupta
2019-07-10  1:14                   ` Rashmica Gupta
2019-07-31 12:08                 ` Michal Hocko
2019-07-31 23:06                   ` Rashmica Gupta
2019-07-31 23:06                     ` Rashmica Gupta
2019-08-01  7:17                     ` Michal Hocko
2019-08-01  7:18                       ` David Hildenbrand
2019-08-01  7:24                         ` Michal Hocko
2019-08-01  7:26                           ` David Hildenbrand
2019-08-01  7:31                             ` David Hildenbrand
2019-08-01  7:39                               ` Michal Hocko
2019-08-01  7:48                                 ` Michal Hocko
2019-08-01  9:18                                   ` David Hildenbrand
2019-08-01  7:34                             ` Michal Hocko
2019-08-01  7:50                               ` David Hildenbrand
2019-08-01  8:04                                 ` Michal Hocko
2019-07-16 12:28             ` David Hildenbrand
2019-07-29  5:42               ` Rashmica Gupta
2019-07-29  5:42                 ` Rashmica Gupta
2019-07-29  8:06                 ` David Hildenbrand
2019-07-30  7:08                   ` Rashmica Gupta
2019-07-30  7:08                     ` Rashmica Gupta
2019-07-31  2:21                   ` Rashmica Gupta
2019-07-31  2:21                     ` Rashmica Gupta
2019-07-31  9:39                     ` David Hildenbrand [this message]

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=5454a6b8-4abc-0922-63a4-a7c0e9d44fcf@redhat.com \
    --to=david@redhat.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@soleen.com \
    --cc=rashmica.g@gmail.com \
    --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.