Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1266216imm; Wed, 6 Jun 2018 13:08:09 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKKEqkHwiwG/yMhNwehPmwQvVDCQWYTwl2hAXNUEJ5XHLAPuEV7wc6rFjp9LGMmj12z6TVs X-Received: by 2002:a17:902:22cc:: with SMTP id o12-v6mr4789251plg.38.1528315688960; Wed, 06 Jun 2018 13:08:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528315688; cv=none; d=google.com; s=arc-20160816; b=MximNJht/MVmcnXJbjIMG4QCmHgXmZUuf+o+fQIHxEkZz6fOidnlyze9m3uv/wGdjT UnU+WOD4FggN7GUrknt7s4t1IOO6uC8AeUiY8yu0Htp0hywq3dlSjkF+dqixx8Ftp2PW 7PuVeQKioeRFSJEKB2SLPgz1/LGuSl68483jKobMcNbloKjBKfCiH2eLHjlJMiK2krH3 2sffXgH7AUM06reEz2C/N0XeEVBlme/IdbROD2qV6Vsj/Hu3V9FPA7t0ja+9Ljr6VdXq BypLoeQCE0ZjkKfrD4dpZw+Fpb6xN4de4R60y//+op1KsxOsFW6icUJLYJVGsdYq1x3z VTng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=iP/EHJVU4MV6wPwBq64vylypmklcCywlEqW00hD9fYQ=; b=PF02I8KKNilTNX9ojM6T1upKgad7Zj7RgdG0PJfUWjXVd4rSG6ItdrjCasoiV4QDDO VJLEFIj5rFBEpe/1S6smCYLN2V7NrDr9qN299WDzl9e6t7ldxHkivESl+6vAjaa8bGq4 /MvfSzwGGNemEM2MDBMBRy1XWm70+hpxFAo5O3vfqxVwf0/hSn7FfykuJjYvHerhKBaN RuJuKzKbdUpkHr5j1iF8Mi4aYteD3E4mN4FU2o87++D+/Cw9fZCrEURjfYQDsKUxB+XU JBA8lkDR+DqXSRiJW7UXpCw4UByAoNhrJ4md5OHNkdJkczp0RnRTRHReyZQ8ytvbtCTq /n9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i64-v6si27282651pgc.673.2018.06.06.13.07.54; Wed, 06 Jun 2018 13:08:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752241AbeFFSQW (ORCPT + 99 others); Wed, 6 Jun 2018 14:16:22 -0400 Received: from mga07.intel.com ([134.134.136.100]:42900 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751812AbeFFSQV (ORCPT ); Wed, 6 Jun 2018 14:16:21 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 11:16:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,484,1520924400"; d="scan'208";a="57090536" Received: from theros.lm.intel.com (HELO linux.intel.com) ([10.232.112.164]) by orsmga003.jf.intel.com with ESMTP; 06 Jun 2018 11:16:20 -0700 Date: Wed, 6 Jun 2018 12:16:19 -0600 From: Ross Zwisler To: Dan Williams Cc: Ross Zwisler , Linux Kernel Mailing List , Dave Jiang , linux-nvdimm Subject: Re: [PATCH v3 2/4] libnvdimm: unconditionally deep flush on *sync Message-ID: <20180606181619.GA13076@linux.intel.com> References: <20180606164515.25677-1-ross.zwisler@linux.intel.com> <20180606164515.25677-2-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 06, 2018 at 10:57:59AM -0700, Dan Williams wrote: > On Wed, Jun 6, 2018 at 9:45 AM, Ross Zwisler > wrote: > > Prior to this commit we would only do a "deep flush" (have nvdimm_flush() > > write to each of the flush hints for a region) in response to an > > msync/fsync/sync call if the nvdimm_has_cache() returned true at the time > > we were setting up the request queue. This happens due to the write cache > > value passed in to blk_queue_write_cache(), which then causes the block > > layer to send down BIOs with REQ_FUA and REQ_PREFLUSH set. We do have a > > "write_cache" sysfs entry for namespaces, i.e.: > > > > /sys/bus/nd/devices/pfn0.1/block/pmem0/dax/write_cache > > > > which can be used to control whether or not the kernel thinks a given > > namespace has a write cache, but this didn't modify the deep flush behavior > > that we set up when the driver was initialized. Instead, it only modified > > whether or not DAX would flush CPU caches via dax_flush() in response to > > *sync calls. > > > > Simplify this by making the *sync deep flush always happen, regardless of > > the write cache setting of a namespace. The DAX CPU cache flushing will > > still be controlled the write_cache setting of the namespace. > > > > Signed-off-by: Ross Zwisler > > Suggested-by: Dan Williams > > Looks, good. I believe we want this one and ["PATCH v3 4/4] libnvdimm: > don't flush power-fail protected CPU caches" marked for -stable and > tagged with: > > Fixes: 5fdf8e5ba566 ("libnvdimm: re-enable deep flush for pmem devices > via fsync()") > > ...any concerns with that? Nope, sounds good. Can you fix that up when you apply, or would it be helpful for me to send another revision with those tags?