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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPcyv4iSJ8e3mgiMb3cG_NEW4VqmuWhHdL2v4Os_xiPSgGLmCg@mail.gmail.com>
Date:	Thu, 20 Aug 2015 11:26:50 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Ross Zwisler <ross.zwisler@...ux.intel.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Borislav Petkov <bp@...e.de>, Christoph Hellwig <hch@....de>,
	Christoph Jaeger <cj@...ux.com>,
	Dan Streetman <ddstreet@...e.org>,
	Ingo Molnar <mingo@...hat.com>,
	Juergen Gross <jgross@...e.com>, Len Brown <lenb@...nel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thierry Reding <treding@...dia.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Toshi Kani <toshi.kani@...com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Will Deacon <will.deacon@....com>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	X86 ML <x86@...nel.org>
Subject: Re: [PATCH v2] nd_blk: add support for "read flush" DSM flag

On Thu, Aug 20, 2015 at 11:17 AM, Ross Zwisler
<ross.zwisler@...ux.intel.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/