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

[Dan Williams]

On Thu, Aug 20, 2015 at 11:17 AM, Ross Zwisler
<ross.zwisler@xxxxxxxxxxxxxxx> wrote:
> On Thu, 2015-08-20 at 10:59 -0700, Dan Williams wrote:
[..]
> Ah, I think we're getting confused about the deinterleave part.
>
> The aperture is a set of contiguous addresses from the perspective of the
> DIMM, but when it's interleaved by the iMC it becomes a bunch of segments that
> are not contiguous in the virtual address space of the kernel.
>
> Meaning, say you have an 8k aperture that is interleaved with one other DIMM
> on a 256 byte granularity - this means that in SPA space you'll end up with a
> big mesh of 256 byte chunks, half of which belong to you and half which don't:
>
> SPA space:
> +--------------------+
> |256 bytes (ours)    |
> +--------------------+
> |256 bytes (not ours)|
> +--------------------+
> |256 bytes (ours)    |
> +--------------------+
> |256 bytes (not ours)|
> +--------------------+
> ...
>
> To be able to flush the entire aperture unconditionally, we have to walk
> through all the segments that belong to use and flush each one of them.  I
> don't think we want to blindly flush the entire interleaved space because a)
> the other chunks are some other DIMMs' apertures, and b) we'd be flushing 2x
> or more (depending on how many DIMMs are interleaved) the space we need, one
> cache line at a time.

I am indeed proposing flushing other DIMMs because those ranges are
invalidated by the aperture moving.  This is based on the assumption
that the flushing is cheaper in the case when no dirty-lines are
found.  The performance gains of doing piecemeal flushes seems not
worth the complexity.
--
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/