From: "Michal Suchánek" <msuchanek@suse.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linux-nvdimm <linux-nvdimm@lists.01.org>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v6 6/8] powerpc/pmem: Avoid the barrier in flush routines
Date: Tue, 30 Jun 2020 10:54:13 +0200 [thread overview]
Message-ID: <20200630085413.GW21462@kitsune.suse.cz> (raw)
In-Reply-To: <CAPcyv4hEV=Ps=t=3qsFq3Ob1jzf=ptoZmYTDkgr8D_G0op8uvQ@mail.gmail.com>
On Mon, Jun 29, 2020 at 06:50:15PM -0700, Dan Williams wrote:
> On Mon, Jun 29, 2020 at 1:41 PM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
> >
> > Michal Suchánek <msuchanek@suse.de> writes:
> >
> > > Hello,
> > >
> > > On Mon, Jun 29, 2020 at 07:27:20PM +0530, Aneesh Kumar K.V wrote:
> > >> nvdimm expect the flush routines to just mark the cache clean. The barrier
> > >> that mark the store globally visible is done in nvdimm_flush().
> > >>
> > >> Update the papr_scm driver to a simplified nvdim_flush callback that do
> > >> only the required barrier.
> > >>
> > >> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> > >> ---
> > >> arch/powerpc/lib/pmem.c | 6 ------
> > >> arch/powerpc/platforms/pseries/papr_scm.c | 13 +++++++++++++
> > >> 2 files changed, 13 insertions(+), 6 deletions(-)
> > >>
> > >> diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
> > >> index 5a61aaeb6930..21210fa676e5 100644
> > >> --- a/arch/powerpc/lib/pmem.c
> > >> +++ b/arch/powerpc/lib/pmem.c
> > >> @@ -19,9 +19,6 @@ static inline void __clean_pmem_range(unsigned long start, unsigned long stop)
> > >>
> > >> for (i = 0; i < size >> shift; i++, addr += bytes)
> > >> asm volatile(PPC_DCBSTPS(%0, %1): :"i"(0), "r"(addr): "memory");
> > >> -
> > >> -
> > >> - asm volatile(PPC_PHWSYNC ::: "memory");
> > >> }
> > >>
> > >> static inline void __flush_pmem_range(unsigned long start, unsigned long stop)
> > >> @@ -34,9 +31,6 @@ static inline void __flush_pmem_range(unsigned long start, unsigned long stop)
> > >>
> > >> for (i = 0; i < size >> shift; i++, addr += bytes)
> > >> asm volatile(PPC_DCBFPS(%0, %1): :"i"(0), "r"(addr): "memory");
> > >> -
> > >> -
> > >> - asm volatile(PPC_PHWSYNC ::: "memory");
> > >> }
> > >>
> > >> static inline void clean_pmem_range(unsigned long start, unsigned long stop)
> > >> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> > >> index 9c569078a09f..9a9a0766f8b6 100644
> > >> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> > >> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> > >> @@ -630,6 +630,18 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> > >>
> > >> return 0;
> > >> }
> > >> +/*
> > >> + * We have made sure the pmem writes are done such that before calling this
> > >> + * all the caches are flushed/clean. We use dcbf/dcbfps to ensure this. Here
> > >> + * we just need to add the necessary barrier to make sure the above flushes
> > >> + * are have updated persistent storage before any data access or data transfer
> > >> + * caused by subsequent instructions is initiated.
> > >> + */
> > >> +static int papr_scm_flush_sync(struct nd_region *nd_region, struct bio *bio)
> > >> +{
> > >> + arch_pmem_flush_barrier();
> > >> + return 0;
> > >> +}
> > >>
> > >> static ssize_t flags_show(struct device *dev,
> > >> struct device_attribute *attr, char *buf)
> > >> @@ -743,6 +755,7 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> > >> ndr_desc.mapping = &mapping;
> > >> ndr_desc.num_mappings = 1;
> > >> ndr_desc.nd_set = &p->nd_set;
> > >> + ndr_desc.flush = papr_scm_flush_sync;
> > >
> > > AFAICT currently the only device that implements flush is virtio_pmem.
> > > How does the nfit driver get away without implementing flush?
> >
> > generic_nvdimm_flush does the required barrier for nfit. The reason for
> > adding ndr_desc.flush call back for papr_scm was to avoid the usage
> > of iomem based deep flushing (ndr_region_data.flush_wpq) which is not
> > supported by papr_scm.
> >
> > BTW we do return NULL for ndrd_get_flush_wpq() on power. So the upstream
> > code also does the same thing, but in a different way.
> >
> >
> > > Also the flush takes arguments that are completely unused but a user of
> > > the pmem region must assume they are used, and call flush() on the
> > > region rather than arch_pmem_flush_barrier() directly.
> >
> > The bio argument can help a pmem driver to do range based flushing in
> > case of pmem_make_request. If bio is null then we must assume a full
> > device flush.
>
> The bio argument isn't for range based flushing, it is for flush
> operations that need to complete asynchronously.
How does the block layer determine that the pmem device needs
asynchronous fushing?
The flush() was designed for the purpose with the bio argument and only
virtio_pmem which is fulshed asynchronously used it. Now that papr_scm
resuses it fir different purpose how do you tell?
Thanks
Michal
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
next prev parent reply other threads:[~2020-06-30 8:54 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 13:57 [PATCH v6 0/8] Support new pmem flush and sync instructions for POWER Aneesh Kumar K.V
2020-06-29 13:57 ` [PATCH v6 1/8] powerpc/pmem: Restrict papr_scm to P8 and above Aneesh Kumar K.V
2020-06-29 13:57 ` [PATCH v6 2/8] powerpc/pmem: Add new instructions for persistent storage and sync Aneesh Kumar K.V
2020-06-29 13:57 ` [PATCH v6 3/8] powerpc/pmem: Add flush routines using new pmem store and sync instruction Aneesh Kumar K.V
2020-06-29 13:57 ` [PATCH v6 4/8] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier Aneesh Kumar K.V
2020-06-29 18:53 ` kernel test robot
2020-06-29 20:27 ` Aneesh Kumar K.V
2020-06-29 19:27 ` kernel test robot
2020-06-29 20:29 ` [PATCH updated] " Aneesh Kumar K.V
2020-06-30 1:32 ` Dan Williams
2020-06-30 5:01 ` Aneesh Kumar K.V
2020-06-30 7:06 ` Dan Williams
2020-06-30 7:22 ` Aneesh Kumar K.V
2020-06-30 7:53 ` Aneesh Kumar K.V
2020-06-30 12:48 ` Aneesh Kumar K.V
2020-06-30 19:21 ` Dan Williams
2020-06-29 13:57 ` [PATCH v6 5/8] powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction Aneesh Kumar K.V
2020-06-30 1:38 ` Dan Williams
2020-06-30 5:05 ` Aneesh Kumar K.V
2020-06-30 7:16 ` Dan Williams
2020-06-29 13:57 ` [PATCH v6 6/8] powerpc/pmem: Avoid the barrier in flush routines Aneesh Kumar K.V
2020-06-29 16:09 ` Michal Suchánek
2020-06-29 20:40 ` Aneesh Kumar K.V
2020-06-30 1:50 ` Dan Williams
2020-06-30 8:54 ` Michal Suchánek [this message]
2020-06-30 9:20 ` Aneesh Kumar K.V
2020-06-30 19:45 ` Dan Williams
2020-07-01 3:09 ` Aneesh Kumar K.V
2020-07-01 5:08 ` Dan Williams
2020-06-29 13:57 ` [PATCH v6 7/8] powerpc/pmem: Add WARN_ONCE to catch the wrong usage of pmem flush functions Aneesh Kumar K.V
2020-06-30 1:52 ` Dan Williams
2020-06-30 5:05 ` Aneesh Kumar K.V
2020-06-29 13:57 ` [PATCH v6 8/8] powerpc/pmem: Initialize pmem device on newer hardware Aneesh Kumar K.V
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=20200630085413.GW21462@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.cz \
--cc=linux-nvdimm@lists.01.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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