[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7c49e493510ce04371d8d6cd6c436c347b1f8469.camel@gmail.com>
Date: Wed, 31 Jul 2019 12:21:16 +1000
From: Rashmica Gupta <rashmica.g@...il.com>
To: David Hildenbrand <david@...hat.com>,
Oscar Salvador <osalvador@...e.de>
Cc: akpm@...ux-foundation.org, mhocko@...e.com,
dan.j.williams@...el.com, pasha.tatashin@...een.com,
Jonathan.Cameron@...wei.com, anshuman.khandual@....com,
vbabka@...e.cz, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/5] Allocate memmap from hotadded memory
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"?
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.
Powered by blists - more mailing lists