Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2891785ybc; Wed, 20 Nov 2019 23:25:29 -0800 (PST) X-Google-Smtp-Source: APXvYqwXFrszEBKzqZ5W1pbv0KVzJtVNXc1D9tz/4v810H2L1dtNYnxZiSwIoJJzn46q4IIZsea2 X-Received: by 2002:a17:906:3602:: with SMTP id q2mr11866318ejb.167.1574321129557; Wed, 20 Nov 2019 23:25:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574321129; cv=none; d=google.com; s=arc-20160816; b=GP67VwraxiwRY4rJRHTO9/kciV6g16vfm+4eG0QXmC5o9GP/zawz95j5ejAcAL8iOS SSwm5arVMFLX3fQm6GN5tgktV8Ke0IH2EKdO7B8qEwpPkk0x/NUS1frzTjS9d5eo+90C OMG9w/Ik1vtHp4O+iEiUutAA+ILvtbF3DdJQ2VYHsdWBJ5h1TH3G99tDup+qol142zGt Wer+s3qBnls6ONllJRRDuxHZIHePt2hQytAXVJcsRpp59TxbxEOYWFHBUiODCpcdRLiV J0AQNy54oxm3Mr9LNC+apAGbExDNK5g6oR0KPiiR6vMlrrFHxCb5Df7Ncf8UJ2bn6e9V c/qQ== 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 :in-reply-to:references:mime-version:dkim-signature; bh=cEXJauHqWm8iI4LnNBvnulW7dvtwyPk4PjbYBEQHLv0=; b=tH+KkTYm60Jv6qccKz5a1OlUyHtG9Fi+mZ1gQfq6UMKYwNT/ykrjND63eYW3rEJ5oh 2tHsKSrjkXCOgaHZUHypcZFISdsd6tT1DSUsgNtHufqx3Mf7f4W5/Fhp3jHJ7dEy9r/J BnsZVRb1tA5Rbd1GD15I9y8eEzGGbHbaDZnh1aHk3r6JLo1T1jnmsPn5wDc2CdH0QDp3 HiQq4G6nBjlsoAE7qiiTR4Nm+5RVWFjKmHaHvu7WU7ax3RXIbpQ5UvJMSG4dAdoU1x5N p5lbmRLn4kFtB3D021gF5Ff2lR3bQJs9IzU4ww9N7UsZdh0VjIX+zPYVr/oLcQ/tf+Hw a5Bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=Aamx4FNU; 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 f18si1182505ejf.210.2019.11.20.23.25.04; Wed, 20 Nov 2019 23:25:29 -0800 (PST) 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=Aamx4FNU; 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 S1726437AbfKUHYA (ORCPT + 99 others); Thu, 21 Nov 2019 02:24:00 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:45019 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725842AbfKUHX7 (ORCPT ); Thu, 21 Nov 2019 02:23:59 -0500 Received: by mail-ot1-f67.google.com with SMTP id c19so2021668otr.11 for ; Wed, 20 Nov 2019 23:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cEXJauHqWm8iI4LnNBvnulW7dvtwyPk4PjbYBEQHLv0=; b=Aamx4FNUou5OK5b7p9ovqCkit0cIfdpUzoZz7zxKIrRXmGuxUroJEy8wgfnhc4LNO9 /bAUGOCzZnxJ+6JvDwrn1hrSEejsJDm9addm6MgSJJndGvNXP5xKWYE3TXfKO3zT1XmE G+cfBCOAa0MLYBx0J8IOpV6ETGNBWcIcBSKsVmQ18T+Av5T94jpinvYdky3C2cfJCxww zAYPLQyi/BjZmHcmFpPXkMpAq93xJVnFAVyNIJ7wM77MNuYDPu5abIu18Pi9wC4fb9Ij LyRjFAPS051ir8jmoxV6RL/1LXpeCK7iPrM3gAOrGb89knq52X47y1B6UQk7Vc8JyaZJ Bxhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cEXJauHqWm8iI4LnNBvnulW7dvtwyPk4PjbYBEQHLv0=; b=EiLOc9Oby8Cucv0gwDx38TMIR3c8KEV9A1YpFe7oM+gTx+X/mnWZxMr0Uoni/1dAS5 oNEESFmbkBOBNFbueWXiWy5c5WYDLYJWO+kJhaSi0MpDKE5pmML87KlK02v5PtLGBT0U N6nJTJXmX7WYlhFwZAK96RlWcwzWBRgDyg0jqL43bSyT0czTb/wZzz/BFtqidNk2GxmD PTguj2FLrCPUnkyx3Y8iPIuTP/J/JFTo17dL9GodKZAo0Al617ES3t8krsgvGE6AhiML tvgCwKERI0YNFEnnAd52ee7r0pHNYLyTdQqvKwaBoGxrek5PbY7XsHvU2sIWMkM5SgYU IHtA== X-Gm-Message-State: APjAAAWbS0jluk+e/yWZ4Jet1e0/50XuDVEedWZ66rBaDrv8QBsfDHz7 rzONzFrtgZ8anxaetUbj1IgnBun/9v/9XaZBRumd5A== X-Received: by 2002:a9d:30c8:: with SMTP id r8mr5394180otg.363.1574321038732; Wed, 20 Nov 2019 23:23:58 -0800 (PST) MIME-Version: 1.0 References: <20191120092831.6198-1-pagupta@redhat.com> In-Reply-To: From: Dan Williams Date: Wed, 20 Nov 2019 23:23:46 -0800 Message-ID: Subject: Re: [PATCH] virtio pmem: fix async flush ordering To: Jeff Moyer Cc: Pankaj Gupta , linux-nvdimm , Linux Kernel Mailing List , Linux ACPI , Vishal L Verma , Dave Jiang , "Weiny, Ira" , "Rafael J. Wysocki" , Len Brown , Vivek Goyal , Keith Busch 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, Nov 20, 2019 at 9:26 AM Jeff Moyer wrote: > > Pankaj Gupta writes: > > > Remove logic to create child bio in the async flush function which > > causes child bio to get executed after parent bio 'pmem_make_request' > > completes. This resulted in wrong ordering of REQ_PREFLUSH with the > > data write request. > > > > Instead we are performing flush from the parent bio to maintain the > > correct order. Also, returning from function 'pmem_make_request' if > > REQ_PREFLUSH returns an error. > > > > Reported-by: Jeff Moyer > > Signed-off-by: Pankaj Gupta > > There's a slight change in behavior for the error path in the > virtio_pmem driver. Previously, all errors from virtio_pmem_flush were > converted to -EIO. Now, they are reported as-is. I think this is > actually an improvement. > > I'll also note that the current behavior can result in data corruption, > so this should be tagged for stable. I added that and was about to push this out, but what about the fact that now the guest will synchronously wait for flushing to occur. The goal of the child bio was to allow that to be an I/O wait with overlapping I/O, or at least not blocking the submission thread. Does the block layer synchronously wait for PREFLUSH requests? If not I think a synchronous wait is going to be a significant performance regression. Are there any numbers to accompany this change?