Received: by 2002:a17:90a:88:0:0:0:0 with SMTP id a8csp4534789pja; Thu, 21 Nov 2019 21:21:50 -0800 (PST) X-Google-Smtp-Source: APXvYqxJWNca4/cgR0Zd7ChrHHILWMwfIGC7zT5xsxAaFwzACFtGzpWw83lMdnSlAF+kwC/DS1aq X-Received: by 2002:a17:906:edd2:: with SMTP id sb18mr20014310ejb.112.1574400110103; Thu, 21 Nov 2019 21:21:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574400110; cv=none; d=google.com; s=arc-20160816; b=hqxYEyX0looqYwRIFCUXvp5SNPt5xuK1x/J/Z9s2P/ER1NgwP7O2ZrwygScCkxzB/4 xXtjS/xvYQWvBy1j7yTaC0/GiZqcNn6Uez9oATgojNx69G2XjIeRkHQINH3O1OJsgBql 1maOOgSpoLziarLjIJ7hERitt8cTMa/2eBOFokwm7iWL7r9vHTUO5KLZD+uitZ5E9jhw pm70eyzW/AJeYr8+DUoMOF+9TX6eCRVwy+nv2TyJ30XpKZ8jeumg0rhhF19JfROjj7MO Lc/5lZ6uQ9U6Aivx7tHJAoe3Oz/gbusJcg39It+60ucr4GBJMp24lsAm2R6X8EnRImGa ZsWQ== 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=keeodVCAfBP266uKFs6gORVjfgMY0eZ+dSw8j1koUJM=; b=CzyXQlN4iNBEcmxrwDXiy39ypgWBpogykq6sCNeVeBqmX2+UvSoZgtqU7dm7hV1O9U yK7wR33p6Y1hSug8Y+vr6arjLkgilme37ZsIOMnXJ1SLI46456xR6sHJu3AMHYD8ZJFz AgWTegpP42eTIMoQYCzkOY0n3cVvA/sQJTLq92EN2SlVP6LkSlfjPTuEA1U5QS9kGVSY wTklA8WYAmDpGPDNc0xFj7U4kwZYQ66FPHIwiD0u9aRB7yWFKn51w5If9lv+7GLfyjQz hMky4D+pr51ERiNEQlrSal9FFUZpilZQr24kps8lF28ONdQ9+T76vPx7xXT+eJP75+3Q FOOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=BIOGnljl; 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 x50si4566887eda.155.2019.11.21.21.21.26; Thu, 21 Nov 2019 21:21:50 -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=BIOGnljl; 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 S1726664AbfKVFRm (ORCPT + 99 others); Fri, 22 Nov 2019 00:17:42 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:33096 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726018AbfKVFRl (ORCPT ); Fri, 22 Nov 2019 00:17:41 -0500 Received: by mail-oi1-f195.google.com with SMTP id m193so5490746oig.0 for ; Thu, 21 Nov 2019 21:17:41 -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=keeodVCAfBP266uKFs6gORVjfgMY0eZ+dSw8j1koUJM=; b=BIOGnljlLRD9J80W8RY8QHF75L0lSFekBNWZN8hg6Rk7ljv9ZJisk86mocS5aiKe4M BRZGCQpb/a/2HBXTpqGHIr6gl5Yi174AJyQgmbRrjnEf1eD4TmgrawnUt12HU3lJfSnM jsv9KaL9by0JkoV7d5CABQDDWhnr3Yv4lsOpRt/wfUrMC3daEO/UP2vIWl/f6F9SjRg6 vV8w8h+6ne19HZGi9F8YO59Tk42WwohDyYShHdM82hUpHeHhD6F2MdT47XhV3HW4jl3e zBa9aicw9PLNxx2NdjnxS7BRDDf9mRGgi26FURoNfyPLFC4eL9NDJ4NpFIDQcLSbfchm nJXg== 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=keeodVCAfBP266uKFs6gORVjfgMY0eZ+dSw8j1koUJM=; b=uAIWeQ4o444yvXk8UyeAitlRZe672Q2s0CLFl+ecoHYnx04YulKTBHYPVhSyr4hNl4 CT70VBeW5XPumHcRBMPKSQDbIqiF6N0O30kq+wJctk6I0aBskcvH/QOdCjmpdeWAd7dZ INWuMiolxtGyPDbBID/hYqWaSgiP1SoHdoAxqvVBPKWxGKmkhcCkvE0cCQG+ssNFFQn/ AqE5WTcCrRSkQPI3MayIcK1ozzkM8+0UfskXT623h/VKilbIbz5fgn6XgFSrONwKc38X um3eDwXWpPvgFsuOgNlPl1jmqzdnW5LkF5LFIGTFgr+FQcXktxHZWs77b7dClcaIYLdN k6jQ== X-Gm-Message-State: APjAAAXt1aavLtvCJyeTePwPY6ZJo/NvGWhXdSIGeV50LKf9k5CjNxYH D9ByXab0AhqK8nuurp0VdF35B/qftCvLM2HLNVX/Bw== X-Received: by 2002:aca:ead7:: with SMTP id i206mr11122498oih.0.1574399860567; Thu, 21 Nov 2019 21:17:40 -0800 (PST) MIME-Version: 1.0 References: <20191120092831.6198-1-pagupta@redhat.com> <1617854972.35808055.1574323227395.JavaMail.zimbra@redhat.com> <560894997.35969622.1574397521533.JavaMail.zimbra@redhat.com> In-Reply-To: <560894997.35969622.1574397521533.JavaMail.zimbra@redhat.com> From: Dan Williams Date: Thu, 21 Nov 2019 21:17:29 -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 8:38 PM 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. > > o.k. Thank you. Will try to post patch today to be considered for 5.4. > I think it is too late for v5.4-final, but we can get it in the -stable queue. Let's take the time to do it right and get some testing on it.