From: Dan Williams <dan.j.williams@intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Luis R. Rodriguez" <mcgrof@suse.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Andrew Morton <akpm@linux-foundation.org>,
Borislav Petkov <bp@suse.de>, Christoph Hellwig <hch@lst.de>,
Christoph Jaeger <cj@linux.com>,
Dan Streetman <ddstreet@ieee.org>, Ingo Molnar <mingo@redhat.com>,
Juergen Gross <jgross@suse.com>, Len Brown <lenb@kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Thierry Reding <treding@nvidia.com>,
Thomas Gleixner <tglx@linutronix.de>,
Toshi Kani <toshi.kani@hp.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Will Deacon <will.deacon@arm.com>,
Yalin Wang <Yalin.Wang@sonymobile.com>,
Linux ACPI <linux-acpi@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
X86 ML <x86@kernel.org>
Subject: Re: [PATCH v2] nd_blk: add support for "read flush" DSM flag
Date: Wed, 19 Aug 2015 16:06:51 -0700 [thread overview]
Message-ID: <CAPcyv4ifZgaQfskPQFGQNhVtnUfkh-Q2au0GjRDYTO60r4F0-g@mail.gmail.com> (raw)
In-Reply-To: <1440024484-26152-1-git-send-email-ross.zwisler@linux.intel.com>
On Wed, Aug 19, 2015 at 3:48 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> Add support for the "read flush" _DSM flag, as outlined in the DSM spec:
>
> http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>
> This flag tells the ND BLK driver that it needs to flush the cache lines
> associated with the aperture after the aperture is moved but before any
> new data is read. This ensures that any stale cache lines from the
> previous contents of the aperture will be discarded from the processor
> cache, and the new data will be read properly from the DIMM. We know
> that the cache lines are clean and will be discarded without any
> writeback because either a) the previous aperture operation was a read,
> and we never modified the contents of the aperture, or b) the previous
> aperture operation was a write and we must have written back the dirtied
> contents of the aperture to the DIMM before the I/O was completed.
>
> By supporting the "read flush" flag we can also change the ND BLK
> aperture mapping from write-combining to write-back via memremap().
>
> In order to add support for the "read flush" flag I needed to add a
> generic routine to invalidate cache lines, mmio_flush_range(). This is
> protected by the ARCH_HAS_MMIO_FLUSH Kconfig variable, and is currently
> only supported on x86.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
[..]
> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
> index 7c2638f..56fff01 100644
> --- a/drivers/acpi/nfit.c
> +++ b/drivers/acpi/nfit.c
[..]
> static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk,
> @@ -1078,11 +1078,16 @@ static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk,
> }
>
> if (rw)
> - memcpy_to_pmem(mmio->aperture + offset,
> + memcpy_to_pmem(mmio->addr.aperture + offset,
> iobuf + copied, c);
> - else
> + else {
> + if (nfit_blk->dimm_flags & ND_BLK_READ_FLUSH)
> + mmio_flush_range((void __force *)
> + mmio->addr.aperture + offset, c);
> +
> memcpy_from_pmem(iobuf + copied,
> - mmio->aperture + offset, c);
> + mmio->addr.aperture + offset, c);
> + }
Why is the flush inside the "while (len)" loop? I think it should be
done immediately after the call to write_blk_ctl() since that is the
point at which the aperture becomes invalidated, and not prior to each
read within a given aperture position. Taking it a bit further, we
may be writing the same address into the control register as was there
previously so we wouldn't need to flush in that case.
next prev parent reply other threads:[~2015-08-19 23:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 22:48 [PATCH v2] nd_blk: add support for "read flush" DSM flag Ross Zwisler
2015-08-19 23:06 ` Dan Williams [this message]
2015-08-20 16:44 ` Ross Zwisler
2015-08-20 17:59 ` Dan Williams
2015-08-20 18:17 ` Ross Zwisler
2015-08-20 18:26 ` Dan Williams
2015-08-20 19:00 ` Ross Zwisler
2015-08-20 20:27 ` Dan Williams
2015-08-20 21:15 ` Ross Zwisler
2015-08-23 1:59 ` Dan Williams
2015-08-20 10:21 ` Will Deacon
2015-08-20 16:08 ` Ross Zwisler
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=CAPcyv4ifZgaQfskPQFGQNhVtnUfkh-Q2au0GjRDYTO60r4F0-g@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=Yalin.Wang@sonymobile.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=cj@linux.com \
--cc=ddstreet@ieee.org \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=mcgrof@suse.com \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=ross.zwisler@linux.intel.com \
--cc=rusty@rustcorp.com.au \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hp.com \
--cc=treding@nvidia.com \
--cc=vishal.l.verma@intel.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.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).