From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751506AbbHTKVy (ORCPT ); Thu, 20 Aug 2015 06:21:54 -0400 Received: from foss.arm.com ([217.140.101.70]:55553 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750877AbbHTKVw (ORCPT ); Thu, 20 Aug 2015 06:21:52 -0400 Date: Thu, 20 Aug 2015 11:21:47 +0100 From: Will Deacon To: Ross Zwisler Cc: "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , "Luis R. Rodriguez" , "Rafael J. Wysocki" , Andrew Morton , Borislav Petkov , Christoph Hellwig , Christoph Jaeger , Dan Streetman , Dan Williams , Ingo Molnar , Juergen Gross , Len Brown , Rusty Russell , Stephen Rothwell , Thierry Reding , Thomas Gleixner , Toshi Kani , Vishal Verma , Yalin Wang , "linux-acpi@vger.kernel.org" , "linux-nvdimm@ml01.01.org" , "x86@kernel.org" Subject: Re: [PATCH v2] nd_blk: add support for "read flush" DSM flag Message-ID: <20150820102147.GB19328@arm.com> References: <1440024484-26152-1-git-send-email-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440024484-26152-1-git-send-email-ross.zwisler@linux.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Will