Re: [PATCH v2] nd_blk: add support for "read flush" DSM flag

[Ross Zwisler]

On Thu, 2015-08-20 at 11:21 +0100, Will Deacon wrote:
> On Wed, Aug 19, 2015 at 11:48:04PM +0100, Ross Zwisler 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.
> 
> Is this operation expected to be implemented as a destructive invalidation
> (i.e. discarding any dirty lines from the cache) or also a writeback of any
> dirtylines as part of the invalidation?
> 
> If its the former, we might want to give it a scarier name to ensure that
> it doesn't grow users outside of NVDIMM scenarios, since "flush" is used
> elsewhere for things like flush_dcache_page.

It is the latter - there will be a writeback of any dirty lines as part of the
invalidation.  The real thing I'm looking for is a forced invalidation
(including writeback, if needed), even on architectures that are cache
coherent.  This is useful when the device can change the data at that memory
location, but not as part of a normal DMA operation that would keep the cache
coherent.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/