linux-kernel - Re: [RFC PATCH 1/7] x86, mm: ZONE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPcyv4ib244VMSdhHDWHRnmCvYdteUEzT+ehTzitSY42m2Tt=w@mail.gmail.com>
Date:	Fri, 14 Aug 2015 14:52:15 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Jerome Glisse <j.glisse@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Boaz Harrosh <boaz@...xistor.com>,
	Rik van Riel <riel@...hat.com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	david <david@...morbit.com>, Ingo Molnar <mingo@...nel.org>,
	Linux MM <linux-mm@...ck.org>, Ingo Molnar <mingo@...hat.com>,
	Mel Gorman <mgorman@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@....de>
Subject: Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"

On Fri, Aug 14, 2015 at 2:37 PM, Jerome Glisse <j.glisse@...il.com> wrote:
> On Wed, Aug 12, 2015 at 11:50:05PM -0400, Dan Williams wrote:
>> While pmem is usable as a block device or via DAX mappings to userspace
>> there are several usage scenarios that can not target pmem due to its
>> lack of struct page coverage. In preparation for "hot plugging" pmem
>> into the vmemmap add ZONE_DEVICE as a new zone to tag these pages
>> separately from the ones that are subject to standard page allocations.
>> Importantly "device memory" can be removed at will by userspace
>> unbinding the driver of the device.
>>
>> Having a separate zone prevents allocation and otherwise marks these
>> pages that are distinct from typical uniform memory.  Device memory has
>> different lifetime and performance characteristics than RAM.  However,
>> since we have run out of ZONES_SHIFT bits this functionality currently
>> depends on sacrificing ZONE_DMA.
>>
>> arch_add_memory() is reorganized a bit in preparation for a new
>> arch_add_dev_memory() api, for now there is no functional change to the
>> memory hotplug code.
>>
>> Cc: H. Peter Anvin <hpa@...or.com>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: Dave Hansen <dave.hansen@...ux.intel.com>
>> Cc: Rik van Riel <riel@...hat.com>
>> Cc: Mel Gorman <mgorman@...e.de>
>> Cc: linux-mm@...ck.org
>> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
>> ---
>>  arch/x86/Kconfig       |   13 +++++++++++++
>>  arch/x86/mm/init_64.c  |   32 +++++++++++++++++++++-----------
>>  include/linux/mmzone.h |   23 +++++++++++++++++++++++
>>  mm/memory_hotplug.c    |    5 ++++-
>>  mm/page_alloc.c        |    3 +++
>>  5 files changed, 64 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index b3a1a5d77d92..64829b17980b 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -308,6 +308,19 @@ config ZONE_DMA
>>
>>         If unsure, say Y.
>>
>> +config ZONE_DEVICE
>> +     bool "Device memory (pmem, etc...) hotplug support" if EXPERT
>> +     default !ZONE_DMA
>> +     depends on !ZONE_DMA
>> +     help
>> +       Device memory hotplug support allows for establishing pmem,
>> +       or other device driver discovered memory regions, in the
>> +       memmap. This allows pfn_to_page() lookups of otherwise
>> +       "device-physical" addresses which is needed for using a DAX
>> +       mapping in an O_DIRECT operation, among other things.
>> +
>> +       If FS_DAX is enabled, then say Y.
>> +
>>  config SMP
>>       bool "Symmetric multi-processing support"
>>       ---help---
>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>> index 3fba623e3ba5..94f0fa56f0ed 100644
>> --- a/arch/x86/mm/init_64.c
>> +++ b/arch/x86/mm/init_64.c
[..]
>> @@ -701,11 +694,28 @@ int arch_add_memory(int nid, u64 start, u64 size)
>>       ret = __add_pages(nid, zone, start_pfn, nr_pages);
>>       WARN_ON_ONCE(ret);
>>
>> -     /* update max_pfn, max_low_pfn and high_memory */
>> -     update_end_of_memory_vars(start, size);
>> +     /*
>> +      * Update max_pfn, max_low_pfn and high_memory, unless we added
>> +      * "device memory" which should not effect max_pfn
>> +      */
>> +     if (!is_dev_zone(zone))
>> +             update_end_of_memory_vars(start, size);
>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/