[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c905918d-54f6-0f17-ca5b-cd3371ada788@intel.com>
Date: Thu, 30 Apr 2020 09:04:23 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: David Hildenbrand <david@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
virtio-dev@...ts.oasis-open.org,
virtualization@...ts.linux-foundation.org,
linuxppc-dev@...ts.ozlabs.org, linux-acpi@...r.kernel.org,
linux-nvdimm@...ts.01.org, linux-hyperv@...r.kernel.org,
linux-s390@...r.kernel.org, xen-devel@...ts.xenproject.org,
Michal Hocko <mhocko@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Michael S . Tsirkin" <mst@...hat.com>,
Michal Hocko <mhocko@...e.com>,
Pankaj Gupta <pankaj.gupta.linux@...il.com>,
Wei Yang <richard.weiyang@...il.com>,
Baoquan He <bhe@...hat.com>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce
MHP_NO_FIRMWARE_MEMMAP
On 4/30/20 8:52 AM, David Hildenbrand wrote:
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
>
> I'd love to get Dan's, Dave's and Michal's opinion.
The impact on kexec from the DAX "kmem" driver's use of hotplug was
inadvertent and unfortunate.
The problem statement and solution seem pretty sane to me.
Powered by blists - more mailing lists