From: Jerome Glisse <j.glisse@gmail.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Boaz Harrosh <boaz@plexistor.com>, Rik van Riel <riel@redhat.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
david <david@fromorbit.com>, Ingo Molnar <mingo@kernel.org>,
Linux MM <linux-mm@kvack.org>, Ingo Molnar <mingo@redhat.com>,
Mel Gorman <mgorman@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"
Date: Tue, 18 Aug 2015 15:06:36 -0400 [thread overview]
Message-ID: <20150818190634.GB7424@gmail.com> (raw)
In-Reply-To: <CAPcyv4hpKHH924B-Udvii5L8xFr04snEA+CLwSMk8mpzsPihkw@mail.gmail.com>
On Tue, Aug 18, 2015 at 10:23:38AM -0700, Dan Williams wrote:
> On Tue, Aug 18, 2015 at 9:55 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> > On Mon, Aug 17, 2015 at 05:46:43PM -0700, Dan Williams wrote:
> >> On Mon, Aug 17, 2015 at 2:45 PM, Jerome Glisse <j.glisse@gmail.com> wrote:
> >> > On Fri, Aug 14, 2015 at 07:11:27PM -0700, Dan Williams wrote:
> >> >> 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.
> >> >
> >> > So i attach is a patch that should keep ZONE_DEVICE out of consideration
> >> > for the buddy allocator. You might also want to keep page reserved and not
> >> > free inside the zone, you could replace the generic_online_page() using
> >> > set_online_page_callback() while hotpluging device memory.
> >> >
> >>
> >> Hmm, are we already protected by the fact that ZONE_DEVICE is not
> >> represented in the GFP_ZONEMASK?
> >
> > Yeah seems you right, high_zoneidx (which is derive using gfp_zone()) will
> > always limit which zones are considered. I thought that under memory presure
> > it would go over all of the zonelist entry and eventualy consider the device
> > zone. But it doesn't seems to be that way.
> >
> > Keeping the device zone out of the zonelist might still be a good idea, if
> > only to avoid pointless iteration for the page allocator. Unless someone can
> > think of a reason why this would be bad.
> >
>
> The other question I have is whether disabling ZONE_DMA is a realistic
> tradeoff for enabling ZONE_DEVICE? I.e. can ZONE_DMA default to off
> going forward, lose some ISA device support, or do we need to figure
> out how to enable > 4 zones.
That require some auditing a quick look and it seems to matter for s390
arch and there is still few driver that use it. I think we can forget
about ISA bus, i would be surprise if you could still run a recent kernel
on a computer that has ISA bus.
Thought maybe you don't need a new ZONE_DEV and all you need is valid
struct page for this device memory, and you don't want this page to be
useable by the general memory allocator. There is surely other ways to
achieve that like marking all as reserved when you hotplug them.
Cheers,
Jerome
--
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>
next prev parent reply other threads:[~2015-08-18 19:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-13 3:50 [RFC PATCH 0/7] 'struct page' driver for persistent memory Dan Williams
2015-08-13 3:50 ` [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory" Dan Williams
2015-08-14 21:37 ` Jerome Glisse
2015-08-14 21:52 ` Dan Williams
2015-08-14 22:06 ` Jerome Glisse
2015-08-14 22:33 ` Dan Williams
2015-08-15 2:11 ` Dan Williams
2015-08-17 21:45 ` Jerome Glisse
2015-08-18 0:46 ` Dan Williams
2015-08-18 16:55 ` Jerome Glisse
2015-08-18 17:23 ` Dan Williams
2015-08-18 19:06 ` Jerome Glisse [this message]
2015-08-20 0:49 ` Dan Williams
2015-08-15 8:59 ` Christoph Hellwig
2015-08-21 15:02 ` Dan Williams
2015-08-21 15:15 ` Jerome Glisse
2015-08-15 13:33 ` Christoph Hellwig
2015-08-13 3:50 ` [RFC PATCH 2/7] x86, mm: introduce struct vmem_altmap Dan Williams
2015-08-13 3:50 ` [RFC PATCH 3/7] x86, mm: arch_add_dev_memory() Dan Williams
2015-08-13 3:50 ` [RFC PATCH 4/7] mm: register_dev_memmap() Dan Williams
2015-08-15 9:04 ` Christoph Hellwig
2015-08-13 3:50 ` [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option Dan Williams
2015-08-15 9:06 ` Christoph Hellwig
2015-08-15 15:28 ` Dan Williams
2015-08-15 15:58 ` Christoph Hellwig
2015-08-15 16:04 ` Dan Williams
2015-08-17 15:01 ` Christoph Hellwig
2015-08-17 15:32 ` Dan Williams
2015-08-13 3:50 ` [RFC PATCH 6/7] libnvdimm, pfn: 'struct page' provider infrastructure Dan Williams
2015-08-13 3:50 ` [RFC PATCH 7/7] libnvdimm, pmem: 'struct page' for pmem Dan Williams
2015-08-15 9:01 ` [RFC PATCH 0/7] 'struct page' driver for persistent memory Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150818190634.GB7424@gmail.com \
--to=j.glisse@gmail.com \
--cc=boaz@plexistor.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=riel@redhat.com \
--cc=ross.zwisler@linux.intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).