Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1209250imm; Wed, 6 Jun 2018 12:09:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIuPF3HH7ADG2qJBB6pdcW8yoEUJJcg1kIs+oLsE0jjRhLJ+MT/PJwLLux56J5DPuZkuFqi X-Received: by 2002:a17:902:8a94:: with SMTP id p20-v6mr4452847plo.258.1528312151034; Wed, 06 Jun 2018 12:09:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528312151; cv=none; d=google.com; s=arc-20160816; b=ACksRIr9X8XmV3Xi7lvoeHGq6lFQop3ci5uaLPwFYco7wXgB5kSiY1iKHrOw0fSWrW kHWhq4A75jNBQwXKSB0wzaIKiDI+475nzsFfQ74GVVVUnq8DZ02pFI4tMdWGp3ES/yD/ fhTMs83w4KRzXmlTlqxs93XNuZguyO8jL0SjdlklZA1FxWeObRmZmIV2rF7uIi0FWDU2 O/crgAGLHzAQ2lu1RCpbXp6hXYiIXND0mMWlvoNqy16M153grXHqqRTVXvUo+KdVbJbW cw7y6S7v2YAibnJcM17cuo6GpoC0/8OiAp8/BtYYiGbe/rYaY8jpq56lV+0djaSEpuWu YKaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=veIi0XlaBrcEmXYuCqOydemDOQSVV3nSI1VMzgkObxo=; b=wp8ePnNd0lGQLIe/kUu6cA74LBW35wQKVnmOGhunYObJxCr89uhrG1bX7eTMnT7z7z sXyACng2Rb/hkbr222/caJA5JluR6D6Ss5tMkYi+mrrj5C9ikUL/d4mVKZ5IsaF2U/sk w6FCAzeTPPqRv8FfevokyT8CnZjgu4gh1qERNEljK8q923s5S/G71TnYCgfc2gm52M7q Zpu1MmlG19xuok9ChYIjMA87Zwlr6XKwNvzkhg8U+NRxYV4zPybRaNZHNv/7hMggo5n4 BfEN6h3dbTCpL/qDPB+2hpX6cRnc01J6nmb0Dh3rYe/y/Mr5i027NM1W1KvuvM14HjsO 6Ihg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=yD2/JIGP; 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 u2-v6si5278482pgv.335.2018.06.06.12.08.52; Wed, 06 Jun 2018 12:09:11 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=yD2/JIGP; 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 S1754079AbeFFR6D (ORCPT + 99 others); Wed, 6 Jun 2018 13:58:03 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:37174 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752609AbeFFR6A (ORCPT ); Wed, 6 Jun 2018 13:58:00 -0400 Received: by mail-oi0-f65.google.com with SMTP id l22-v6so6087951oib.4 for ; Wed, 06 Jun 2018 10:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=veIi0XlaBrcEmXYuCqOydemDOQSVV3nSI1VMzgkObxo=; b=yD2/JIGPr3k/6wznFRxH++NtDFTfRz6GRqqhKsaSKVGyjfgIfhdwpFeTxcGDzWiII6 RWyzzzyKpoWXdd7k2uAoT5XIkhOvH89eU+RozrpYC1UOohq99/QjvxCrludDVWunyIKm s4tlqyxU8hw5iCWD4cNQbTJddpzlzgAd67s9VEVGDiC+7RA3zqU6fgSMZ1cSO4Sktg6U FhzclsuTITuyIZ2i2CpF97EHqzRMvTHEUa/p/1zP9e3SYTabm2sFLpGtxzeH4yRzq6z6 D44W4pfew7BTp7nHognS6nvdjfRM2lbV+LO716SjFNoQH4g9CN3lAmd/ijO+s0t2PY4o 1dsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=veIi0XlaBrcEmXYuCqOydemDOQSVV3nSI1VMzgkObxo=; b=a3pyGiwIkKc2O6ifsRVsMfbcnICLJs0XpgkhqbftBvsQVCX4pMNX0hjo++HRt43LYd 5mdcvoK5RFA6bOq3ZYk0A0V5NU6VsHqcrrusYcsdn50Gj8a/GRCxk80PxDb4CyTYqWNR c6kkuFhoKjsOchUPebQgKFmsZqh2D6T5linuU4Yfgtp2lBgHCEEaktFbz2NmUuaJXz9c xbbrgpt4Xm/OxQFcB4/vmuHQ4yAGIz3GCUmpNP8A4rUC/S9uFrBnecL/gpcC1MN07N6C EYoMD2Q9uKlBwmtLqY5IZEn4tBSTK8u14u1obAMajFnsVBHsHG6cmCh1IxTz5dQQDaw3 lsNA== X-Gm-Message-State: APt69E1mLwoFHMl6YifQtQpk5U4OD1wH7xGjtQFWD+7wbxfJPM2tmiMC iFjgVvUOQ7TnRpLGpP+DZgEakgTVConkQfrazXNUgQ== X-Received: by 2002:aca:a902:: with SMTP id s2-v6mr2343607oie.72.1528307880335; Wed, 06 Jun 2018 10:58:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2ea9:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 10:57:59 -0700 (PDT) In-Reply-To: <20180606164515.25677-2-ross.zwisler@linux.intel.com> References: <20180606164515.25677-1-ross.zwisler@linux.intel.com> <20180606164515.25677-2-ross.zwisler@linux.intel.com> From: Dan Williams Date: Wed, 6 Jun 2018 10:57:59 -0700 Message-ID: Subject: Re: [PATCH v3 2/4] libnvdimm: unconditionally deep flush on *sync To: Ross Zwisler Cc: Linux Kernel Mailing List , Dave Jiang , linux-nvdimm Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?