Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3427776ybc; Thu, 21 Nov 2019 08:12:10 -0800 (PST) X-Google-Smtp-Source: APXvYqwihVc2g1tzQQAW5pDqTiHifZ2AjvAxrCsNUG3SflB0s1nk1T//IgUlCSPyn9Fw2QOkTli7 X-Received: by 2002:a19:c384:: with SMTP id t126mr8506806lff.100.1574352730113; Thu, 21 Nov 2019 08:12:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574352730; cv=none; d=google.com; s=arc-20160816; b=xPkaMW0qb5qqJ5po/oTxdhyYu/Zs65VVOxuww8ddLM/PKD0ei1B5Nf2OJA4NHwyUTD m9reCLTapsPIpTnPCYYgjCBdP+Wn//Q1pCcBz+PEg9GklZ7LHfbHl+2iKNfAqVbkDKyt 24BhdvbBfNa9QjFolGcqmNPvNFbTJqGTXzhnZ4dUa9D3957Ks8U8BAEBLpCb8sb6UO70 ntzsJ1fQMnnUJPR3uMmayUcOT8QqwttBVYXtfvsjxgzEt/IWXYU/ZOnTXzkHCDpOuLkP m8/nYEzhce0yENOKxjXPDpBah/bIBQAV7twqDhVQfZ84OAEg7dEOEZjHu7fbRMgLbU+q r8uA== 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=gXcgcbvs+2MnPA/4X38cmSpaLsc4tBMazAvEwqgqGLo=; b=UNha29R/jfyl0So9XIw/knR98pLiZJzt8AkjGw9XDqXjyUHOegeugV7OdBqTkHqAEa LWCZeAzUv11mYK6c7JI6g2WLDZAocIKeQgR2PdhzHncwep2fO78hSnmCoIzI1pqTXYZc Gtme/Cz5CNVsB7y+uC55pexrgyR/3Zyi7bxz+wTIjD/tYXCGonyeTpPf370LdcHlQ5LE F9lMf/IRco+Y3t1WLdwhJdDg6oQQBs+v9nwWNWVKA1leXubbiDBazfb/DH0bFIXZmzMU 9pzaQE35Zitg21Mxpmvrt680s+D/itc+XHWe/eRuchS+06cWKhEwX7KoPGFE0iqAxOGv uufg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="UE/6TT7H"; 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 kq26si1529155ejb.357.2019.11.21.08.11.45; Thu, 21 Nov 2019 08:12:10 -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="UE/6TT7H"; 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 S1727046AbfKUQJO (ORCPT + 99 others); Thu, 21 Nov 2019 11:09:14 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:33872 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726293AbfKUQJO (ORCPT ); Thu, 21 Nov 2019 11:09:14 -0500 Received: by mail-oi1-f193.google.com with SMTP id l202so3698347oig.1 for ; Thu, 21 Nov 2019 08:09:13 -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=gXcgcbvs+2MnPA/4X38cmSpaLsc4tBMazAvEwqgqGLo=; b=UE/6TT7HfPuj8S5WgeIZ69I021cjsb4qGDZt3qc9fk1IB5APVoH66ut51jVBes4iSW Aef0fLKZocovV80FGW/O+Gv57tCW1pRhplxGliybAKG42xLiMrtbqrEIgCZ6c+KmfCnf dgvaBxYJ35Q4ov8s6LeUCSJ9dYGNH8PcnuIi4h6Cd61vCgrzzcoQi7EHEGMv6fGYmXFq ZiKVURucVh43UjBdWpw4DNKYA1CKXYHftPdvH2B0cR4G3F+T+udGHGGCvHw31xJf3qSy xTb97wVqCQKA608tb1v79CHsPYi02hOh3NrGphXwbN+jVtzlRPeKPQCB+mCUZPdYStwN m24A== 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=gXcgcbvs+2MnPA/4X38cmSpaLsc4tBMazAvEwqgqGLo=; b=OTJ2OEA6Ugt074iXNanHgvX9EnTkXZQ4WLUqsuA7Vbpd+rRcpZniq7RUUw9p98qa7g eTqQn6DBYMJYyAZqEs3bSeAByXY/BHJVspm6KRTQ6isSR6NGAFpZQ/O7BJyl5d1DUAnj E6UhO9wyjISg/2SaLAX+zfRNjG7EIA9D4U5xxWa5Az3xGYBYyVxVrRuGtrPxmq6yYGRB Lv0JtEXN/Vz8BSED/ZEgdBWmcQ7wITEZCWqRcdUqrPts6bdEHUnrk6SEQJ434Hj59c09 Suzdj1EKtbdLaAVGQmQFWyHj4XvCLTioITDEGfOxQbxOVlI6ry6GLOrPDEqXc+GAg1eY UBjg== X-Gm-Message-State: APjAAAVI2bIiklHmKyeNoLNcoKSY/diKeC6qugBV4tdBd36PZDxI2m5m l0Cpo8JcIEwK3JMYGS7SZz41S+21B5Kjp5b7oT36VA== X-Received: by 2002:aca:3c1:: with SMTP id 184mr7837409oid.70.1574352553381; Thu, 21 Nov 2019 08:09:13 -0800 (PST) MIME-Version: 1.0 References: <20191120092831.6198-1-pagupta@redhat.com> <1617854972.35808055.1574323227395.JavaMail.zimbra@redhat.com> In-Reply-To: <1617854972.35808055.1574323227395.JavaMail.zimbra@redhat.com> From: Dan Williams Date: Thu, 21 Nov 2019 08:09:02 -0800 Message-ID: Subject: Re: [PATCH] virtio pmem: fix async flush ordering To: Pankaj Gupta Cc: Jeff Moyer , linux-nvdimm , Linux Kernel Mailing List , Linux ACPI , Vishal L Verma , Dave Jiang , Ira Weiny , "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 Thu, Nov 21, 2019 at 12:00 AM Pankaj Gupta wrote: > > > > > > > > > > > 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? > > > > Why not just swap the parent child relationship in the PREFLUSH case? > > I we are already inside parent bio "make_request" function and we create child > bio. How we exactly will swap the parent/child relationship for PREFLUSH case? > > Child bio is queued after parent bio completes. Sorry, I didn't quite mean with bio_split, but issuing another request in front of the real bio. See md_flush_request() for inspiration.