On Fri, Aug 14, 2015 at 3:33 PM, Dan Williams <dan.j.williams(a)intel.com> wrote:
On Fri, Aug 14, 2015 at 3:06 PM, Jerome Glisse
> On Fri, Aug 14, 2015 at 02:52:15PM -0700, Dan Williams wrote:
>> On Fri, Aug 14, 2015 at 2:37 PM, Jerome Glisse <j.glisse(a)gmail.com> wrote:
>> > On Wed, Aug 12, 2015 at 11:50:05PM -0400, Dan Williams wrote:
>> > 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.
> 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.