Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"
From: Dan Williams <hidden>
Date: 2015-08-15 02:11:29
Also in:
lkml, nvdimm
On Fri, Aug 14, 2015 at 3:33 PM, Dan Williams [off-list ref] wrote:
On Fri, Aug 14, 2015 at 3:06 PM, Jerome Glisse [off-list ref] wrote:quoted
On Fri, Aug 14, 2015 at 02:52:15PM -0700, Dan Williams wrote:quoted
On Fri, Aug 14, 2015 at 2:37 PM, Jerome Glisse [off-list ref] wrote:quoted
On Wed, Aug 12, 2015 at 11:50:05PM -0400, Dan Williams wrote:[..]quoted
quoted
quoted
What is the rational for not updating max_pfn, max_low_pfn, ... ?The idea is that this memory is not meant to be available to the page allocator and should not count as new memory capacity. We're only hotplugging it to get struct page coverage.But this sounds bogus to me to rely on max_pfn to stay smaller than first_dev_pfn. For instance you might plug a device that register dev memory and then some regular memory might be hotplug, effectively updating max_pfn to a value bigger than first_dev_pfn.True.quoted
Also i do not think that the buddy allocator use max_pfn or max_low_pfn to consider page/zone for allocation or not.Yes, I took it out with no effects. I'll investigate further whether we should be touching those variables or not for this new usage.
Although it does not offer perfect protection if device memory is at a physically lower address than RAM, skipping the update of these variables does seem to be what we want. For example /dev/mem would fail to allow write access to persistent memory if it fails a valid_phys_addr_range() check. Since /dev/mem does not know how to write to PMEM in a reliably persistent way, it should not treat a PMEM-pfn like RAM. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>