From: Stephen Bates <sbates@raithlin.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-rdma@vger.kernel.org, linux-block@vger.kernel.org,
Linux MM <linux-mm@kvack.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Matthew Wilcox <willy@linux.intel.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
haggaie@mellanox.com, Christoph Hellwig <hch@infradead.org>,
Jens Axboe <axboe@fb.com>, Jonathan Corbet <corbet@lwn.net>,
jim.macdonald@everspin.com, sbates@raithin.com,
Logan Gunthorpe <logang@deltatee.com>
Subject: Re: [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.
Date: Tue, 25 Oct 2016 05:54:09 -0600 [thread overview]
Message-ID: <20161025115409.GB14986@cgy1-donard.priv.deltatee.com> (raw)
In-Reply-To: <CAPcyv4iTFpZ1b74Wf+qWe9=Annp+-OCy+pFMS7Fo7quUFwhM4g@mail.gmail.com>
On Wed, Oct 19, 2016 at 01:01:06PM -0700, Dan Williams wrote:
> >>
> >> In the cover letter, "[PATCH 0/3] iopmem : A block device for PCIe
> >> memory", it mentions that the lack of I/O coherency is a known issue
> >> and users of this functionality need to be cognizant of the pitfalls.
> >> If that is the case why do we need support for different cpu mapping
> >> types than the default write-back cache setting? It's up to the
> >> application to handle cache cpu flushing similar to what we require of
> >> device-dax users in the persistent memory case.
> >
> > Some of the iopmem hardware we have tested has certain alignment
> > restrictions on BAR accesses. At the very least we require write
> > combine mappings for these. We then felt it appropriate to add the
> > other mappings for the sake of completeness.
>
> If the device can support write-combine then it can support bursts, so
> I wonder why it couldn't support read bursts for cache fills...
Dan
You make a good point. We did some testing on this and for the HW we
have access too we did see that a standard WB mapping worked.
Interestly though the local access performance was much slower than
for the WC mapping. We also noticed the PAT entries we not marked
correctly in the WB case. I am trying to get access to some other HW
for more testing.
Grepping for the address of interest:
In WB mode it's:
uncached-minus @ 0x381f80000000-0x381fc0000000
In WC mode it's:
write-combining @ 0x381f80000000-0x381fc0000000
Cheers
Stephen
--
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:[~2016-10-25 11:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 21:42 [PATCH 0/3] iopmem : A block device for PCIe memory Stephen Bates
2016-10-18 21:42 ` [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages Stephen Bates
2016-10-19 17:50 ` Dan Williams
2016-10-19 18:40 ` Stephen Bates
2016-10-19 20:01 ` Dan Williams
2016-10-25 11:54 ` Stephen Bates [this message]
2016-10-18 21:42 ` [PATCH 2/3] iopmem : Add a block device driver for PCIe attached IO memory Stephen Bates
2016-10-28 6:45 ` Christoph Hellwig
2016-10-28 19:22 ` Logan Gunthorpe
2016-10-18 21:42 ` [PATCH 3/3] iopmem : Add documentation for iopmem driver Stephen Bates
2016-10-28 6:46 ` Christoph Hellwig
2016-10-19 3:51 ` [PATCH 0/3] iopmem : A block device for PCIe memory Dan Williams
2016-10-19 18:48 ` Stephen Bates
2016-10-19 19:58 ` Dan Williams
2016-10-19 22:54 ` Stephen Bates
2016-10-20 23:22 ` Dave Chinner
2016-10-21 9:57 ` Christoph Hellwig
2016-10-21 11:12 ` Dave Chinner
2016-10-25 11:50 ` Stephen Bates
2016-10-25 21:19 ` Dave Chinner
2016-11-06 14:05 ` Stephen Bates
2016-10-27 10:22 ` Sagi Grimberg
2016-10-27 12:32 ` Christoph Hellwig
2016-10-26 8:24 ` Haggai Eran
2016-10-26 13:39 ` Dan Williams
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=20161025115409.GB14986@cgy1-donard.priv.deltatee.com \
--to=sbates@raithlin.com \
--cc=axboe@fb.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=haggaie@mellanox.com \
--cc=hch@infradead.org \
--cc=jgunthorpe@obsidianresearch.com \
--cc=jim.macdonald@everspin.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-rdma@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=ross.zwisler@linux.intel.com \
--cc=sbates@raithin.com \
--cc=willy@linux.intel.com \
/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