From: Toshi Kani <toshi.kani@hp.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>, "hch@lst.de" <hch@lst.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@kernel.org" <mingo@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
"boaz@plexistor.com" <boaz@plexistor.com>,
"david@fromorbit.com" <david@fromorbit.com>
Subject: Re: [PATCH v2 5/9] x86, pmem: push fallback handling to arch code
Date: Fri, 28 Aug 2015 15:41:24 -0600 [thread overview]
Message-ID: <1440798084.14237.106.camel@hp.com> (raw)
In-Reply-To: <1440624859.31365.17.camel@intel.com>
On Wed, 2015-08-26 at 21:34 +0000, Williams, Dan J wrote:
> On Wed, 2015-08-26 at 14:41 +0200, Christoph Hellwig wrote:
> > I like the intent behind this, but not the implementation.
> >
> > I think the right approach is to keep the defaults in linux/pmem.h
> > and simply not set CONFIG_ARCH_HAS_PMEM_API for x86-32.
>
> Yes, that makes things much cleaner. Revised patch and changelog below:
>
> 8<----
> Subject: x86, pmem: clarify that ARCH_HAS_PMEM_API implies PMEM mapped WB
>
> From: Dan Williams <dan.j.williams@intel.com>
>
> Given that a write-back (WB) mapping plus non-temporal stores is
> expected to be the most efficient way to access PMEM, update the
> definition of ARCH_HAS_PMEM_API to imply arch support for
> WB-mapped-PMEM. This is needed as a pre-requisite for adding PMEM to
> the direct map and mapping it with struct page.
>
> The above clarification for X86_64 means that memcpy_to_pmem() is
> permitted to use the non-temporal arch_memcpy_to_pmem() rather than
> needlessly fall back to default_memcpy_to_pmem() when the pcommit
> instruction is not available. When arch_memcpy_to_pmem() is not
> guaranteed to flush writes out of cache, i.e. on older X86_32
> implementations where non-temporal stores may just dirty cache,
> ARCH_HAS_PMEM_API is simply disabled.
>
> The default fall back for persistent memory handling remains. Namely,
> map it with the WT (write-through) cache-type and hope for the best.
>
> arch_has_pmem_api() is updated to only indicate whether the arch
> provides the proper helpers to meet the minimum "writes are visible
> outside the cache hierarchy after memcpy_to_pmem() + wmb_pmem()". Code
> that cares whether wmb_pmem() actually flushes writes to pmem must now
> call arch_has_wmb_pmem() directly.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Cc: Christoph Hellwig <hch@lst.de>
> [hch: set ARCH_HAS_PMEM_API=n on X86_32]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Thanks for making this change! It looks good.
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
I have one minor comment below:
> ---
> arch/x86/Kconfig | 2 +-
> arch/x86/include/asm/io.h | 2 --
> arch/x86/include/asm/pmem.h | 8 ++------
> drivers/acpi/nfit.c | 2 +-
> drivers/nvdimm/pmem.c | 2 +-
> include/linux/pmem.h | 28 +++++++++++++++++-----------
> 6 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 76c61154ed50..5912859df533 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -27,7 +27,7 @@ config X86
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FAST_MULTIPLIER
> select ARCH_HAS_GCOV_PROFILE_ALL
> - select ARCH_HAS_PMEM_API
> + select ARCH_HAS_PMEM_API if X86_64
> select ARCH_HAS_SG_CHAIN
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index d241fbd5c87b..83ec9b1d77cc 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -248,8 +248,6 @@ static inline void flush_write_buffers(void)
> #endif
> }
>
> -#define ARCH_MEMREMAP_PMEM MEMREMAP_WB
Should it be better to do:
#else /* !CONFIG_ARCH_HAS_PMEM_API */
#define ARCH_MEMREMAP_PMEM MEMREMAP_WT
so that you can remove all '#ifdef ARCH_MEMREMAP_PMEM' stuff?
Thanks,
-Toshi
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Toshi Kani <toshi.kani@hp.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>, "hch@lst.de" <hch@lst.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@kernel.org" <mingo@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
"boaz@plexistor.com" <boaz@plexistor.com>,
"david@fromorbit.com" <david@fromorbit.com>
Subject: Re: [PATCH v2 5/9] x86, pmem: push fallback handling to arch code
Date: Fri, 28 Aug 2015 15:41:24 -0600 [thread overview]
Message-ID: <1440798084.14237.106.camel@hp.com> (raw)
In-Reply-To: <1440624859.31365.17.camel@intel.com>
On Wed, 2015-08-26 at 21:34 +0000, Williams, Dan J wrote:
> On Wed, 2015-08-26 at 14:41 +0200, Christoph Hellwig wrote:
> > I like the intent behind this, but not the implementation.
> >
> > I think the right approach is to keep the defaults in linux/pmem.h
> > and simply not set CONFIG_ARCH_HAS_PMEM_API for x86-32.
>
> Yes, that makes things much cleaner. Revised patch and changelog below:
>
> 8<----
> Subject: x86, pmem: clarify that ARCH_HAS_PMEM_API implies PMEM mapped WB
>
> From: Dan Williams <dan.j.williams@intel.com>
>
> Given that a write-back (WB) mapping plus non-temporal stores is
> expected to be the most efficient way to access PMEM, update the
> definition of ARCH_HAS_PMEM_API to imply arch support for
> WB-mapped-PMEM. This is needed as a pre-requisite for adding PMEM to
> the direct map and mapping it with struct page.
>
> The above clarification for X86_64 means that memcpy_to_pmem() is
> permitted to use the non-temporal arch_memcpy_to_pmem() rather than
> needlessly fall back to default_memcpy_to_pmem() when the pcommit
> instruction is not available. When arch_memcpy_to_pmem() is not
> guaranteed to flush writes out of cache, i.e. on older X86_32
> implementations where non-temporal stores may just dirty cache,
> ARCH_HAS_PMEM_API is simply disabled.
>
> The default fall back for persistent memory handling remains. Namely,
> map it with the WT (write-through) cache-type and hope for the best.
>
> arch_has_pmem_api() is updated to only indicate whether the arch
> provides the proper helpers to meet the minimum "writes are visible
> outside the cache hierarchy after memcpy_to_pmem() + wmb_pmem()". Code
> that cares whether wmb_pmem() actually flushes writes to pmem must now
> call arch_has_wmb_pmem() directly.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Cc: Christoph Hellwig <hch@lst.de>
> [hch: set ARCH_HAS_PMEM_API=n on X86_32]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Thanks for making this change! It looks good.
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
I have one minor comment below:
> ---
> arch/x86/Kconfig | 2 +-
> arch/x86/include/asm/io.h | 2 --
> arch/x86/include/asm/pmem.h | 8 ++------
> drivers/acpi/nfit.c | 2 +-
> drivers/nvdimm/pmem.c | 2 +-
> include/linux/pmem.h | 28 +++++++++++++++++-----------
> 6 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 76c61154ed50..5912859df533 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -27,7 +27,7 @@ config X86
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FAST_MULTIPLIER
> select ARCH_HAS_GCOV_PROFILE_ALL
> - select ARCH_HAS_PMEM_API
> + select ARCH_HAS_PMEM_API if X86_64
> select ARCH_HAS_SG_CHAIN
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index d241fbd5c87b..83ec9b1d77cc 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -248,8 +248,6 @@ static inline void flush_write_buffers(void)
> #endif
> }
>
> -#define ARCH_MEMREMAP_PMEM MEMREMAP_WB
Should it be better to do:
#else /* !CONFIG_ARCH_HAS_PMEM_API */
#define ARCH_MEMREMAP_PMEM MEMREMAP_WT
so that you can remove all '#ifdef ARCH_MEMREMAP_PMEM' stuff?
Thanks,
-Toshi
next prev parent reply other threads:[~2015-08-28 21:41 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 1:27 [PATCH v2 0/9] initial struct page support for pmem Dan Williams
2015-08-26 1:27 ` Dan Williams
2015-08-26 1:27 ` [PATCH v2 1/9] dax: drop size parameter to ->direct_access() Dan Williams
2015-08-26 1:27 ` Dan Williams
2015-08-26 1:27 ` [PATCH v2 2/9] mm: move __phys_to_pfn and __pfn_to_phys to asm/generic/memory_model.h Dan Williams
2015-08-26 1:27 ` Dan Williams
2015-09-18 23:42 ` Tyler Baker
2015-09-18 23:42 ` Tyler Baker
2015-09-18 23:59 ` Dan Williams
2015-09-18 23:59 ` Dan Williams
2015-09-19 6:49 ` Tyler Baker
2015-09-19 6:49 ` Tyler Baker
2015-09-29 19:21 ` Nicolas Pitre
2015-09-29 19:21 ` Nicolas Pitre
2015-09-29 19:36 ` Tyler Baker
2015-09-29 19:36 ` Tyler Baker
2015-09-29 19:36 ` Tyler Baker
2015-09-29 19:47 ` Nicolas Pitre
2015-09-29 19:47 ` Nicolas Pitre
2015-09-29 19:47 ` Nicolas Pitre
2015-08-26 1:27 ` [PATCH v2 3/9] mm: ZONE_DEVICE for "device memory" Dan Williams
2015-08-26 1:27 ` Dan Williams
2015-08-26 1:27 ` [PATCH v2 4/9] add devm_memremap_pages Dan Williams
2015-08-26 1:27 ` Dan Williams
2015-08-26 1:27 ` [PATCH v2 5/9] x86, pmem: push fallback handling to arch code Dan Williams
2015-08-26 1:27 ` Dan Williams
2015-08-26 12:41 ` Christoph Hellwig
2015-08-26 12:41 ` Christoph Hellwig
2015-08-26 21:34 ` Williams, Dan J
2015-08-26 21:34 ` Williams, Dan J
2015-08-27 7:33 ` hch
2015-08-27 7:33 ` hch
2015-08-28 20:22 ` Ross Zwisler
2015-08-28 20:22 ` Ross Zwisler
2015-08-28 21:41 ` Toshi Kani [this message]
2015-08-28 21:41 ` Toshi Kani
2015-08-28 21:47 ` Dan Williams
2015-08-28 21:47 ` Dan Williams
2015-08-28 21:48 ` Toshi Kani
2015-08-28 21:48 ` Toshi Kani
2015-08-29 4:04 ` Williams, Dan J
2015-08-29 4:04 ` Williams, Dan J
2015-08-29 13:57 ` hch
2015-08-29 13:57 ` hch
2015-08-26 1:27 ` [PATCH v2 6/9] libnvdimm, pfn: 'struct page' provider infrastructure Dan Williams
2015-08-26 1:27 ` Dan Williams
2015-08-26 1:28 ` [PATCH v2 7/9] libnvdimm, pmem: 'struct page' for pmem Dan Williams
2015-08-26 1:28 ` Dan Williams
2015-08-26 1:28 ` [PATCH v2 8/9] libnvdimm, pmem: direct map legacy pmem by default Dan Williams
2015-08-26 1:28 ` Dan Williams
2015-08-26 1:28 ` [PATCH v2 9/9] devm_memremap_pages: protect against pmem device unbind Dan Williams
2015-08-26 1:28 ` Dan Williams
2015-08-26 12:46 ` Christoph Hellwig
2015-08-26 12:46 ` Christoph Hellwig
2015-08-26 21:39 ` Williams, Dan J
2015-08-26 21:39 ` Williams, Dan J
2015-08-27 7:33 ` hch
2015-08-27 7:33 ` hch
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=1440798084.14237.106.camel@hp.com \
--to=toshi.kani@hp.com \
--cc=boaz@plexistor.com \
--cc=dan.j.williams@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=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=ross.zwisler@linux.intel.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.