Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2900022ybc; Wed, 20 Nov 2019 23:35:58 -0800 (PST) X-Google-Smtp-Source: APXvYqyJwwZxP92+1ZQ84RrbJGy/G+1zAqP1NEvj8y5Uy9RBFNhFaV0Pb718mX0+7lNphJWWQRga X-Received: by 2002:a17:906:4d58:: with SMTP id b24mr11682692ejv.277.1574321758628; Wed, 20 Nov 2019 23:35:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574321758; cv=none; d=google.com; s=arc-20160816; b=CvzhTqvsCYuY/CUBcYdnaIC0cEygJrQKm7QsAmI+GUcF1AxJ23ocRwhdbIVgZ2JFJV RTM4bw7CLD21I0D8gvduMTwg70hIWg/ZaX7FmqBSxLf4jPh5k8tStm5qppNR0eJTE9dw PPJHh6IPHWBVyXp313PPHuga1g322ixtZsUmN2LkLsJSw2fMhnfI+qjzWFx84wpVuRpY Ks7Yn8n+MqH6BcuOvVh/R5G9XTDJuA66CL4clWLTpNfVqemnayV0ZTnpATTjqDYYcm4L Gu28XaW3+Dpjo2mCaMuB9zmoBFjkwtEEpomTX5S1PnF6hbOgQ2ZjZUex2fq4eWCgvXXY UqGg== 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=w9wDawpHcea7HfUbnxzvdCHT/HpQNck9P448/UedoQM=; b=aTxSCjL1BVsxdP4Egv7Yu6dH96eu6KluKjqTAup2aLTq6wgoF0KcIuInn/k0PcZqBU fS1R6g+zed/88abJwlnGcg6c6z0rOzmO2Wuni65h/dbN/zAlGxTw18S/1BoDU5fmzH1G PzMygCdeli7dx+ub2+xuaRwXzBLIa75B0kigasXSxF3kHepYtHiagMXJz/NKKX36xEBR 4MIPfKFuw+uPIzu8YJQ1mnPYEUFgBNDSxsHkzFAyEMqipN6d275hWk61WDUSUBFo0zM/ RDbWMkl86nEw4V5BdqY2Mwvomd4I0yeh9Hi/U4TyZH5/xTTQodMi2Qkx2k0TMi4NQuM4 PQXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=RUey+MSk; 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 x12si1134975eju.50.2019.11.20.23.35.34; Wed, 20 Nov 2019 23:35:58 -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=RUey+MSk; 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 S1726803AbfKUHc3 (ORCPT + 99 others); Thu, 21 Nov 2019 02:32:29 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:37294 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726230AbfKUHc3 (ORCPT ); Thu, 21 Nov 2019 02:32:29 -0500 Received: by mail-ot1-f65.google.com with SMTP id d5so2089389otp.4 for ; Wed, 20 Nov 2019 23:32:28 -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=w9wDawpHcea7HfUbnxzvdCHT/HpQNck9P448/UedoQM=; b=RUey+MSk1Jxsoa8ZqmDeOeA4Qu0lkrGc8OKXCXqKYlNDPNE/RI693KUy2YDy1bs0Bq ckWMixCAW5axJ3kJe7EpdMPizq+94X82FKhtwD7vIIOrm5PL4rWL5tMsRQc+gCoqi2TK RVgk0Kg9QPwUIVbMM59J11QqVgfeIgZPu4jOo1P8CBl7ke4N9DJQqfgylUSmvoKQKCbj mBjTqC/uvyUH/7bVZEmz7QQpfP5gtFAcrfBHGIuVQoZJNq8iC+Dgu0eAy4vcTOSab/Fh 5mD7rv1Vz3M2bsNxX5R/1UKzn0KB1ehwLLvkMlxZ8kQlbvrKCCz1llIjyOUowure8p6X BRpg== 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=w9wDawpHcea7HfUbnxzvdCHT/HpQNck9P448/UedoQM=; b=Q3ohUa6tph1eAZVv6CdQ665C6SgqF97EmoGUWRr/teadRy+xm1gbZBmHoTQj5OMTEU c7Vj9QcVQG9AoBNnucN9dbKUgl21jQVL9ZOn5Of+Gx2I2B75B/Uno2W8O7EBU0H99baK 1hBjD31Mfeqk67WiKYViNG5U/FrvgVBDVrw65lByfODObvvzpDSkoXxGKFD2hkzLU0GR rhIj+Kvukvw20SdWVWbQ4p4XtxwHapIkVmP+oQHfUl79oQCn5TTpxDa4cnA4L0ptX9yg vBBLnuZsBJqPfuniXTsMDkbUajTLAN8hYGGOUw3OEtQ1TMQqK6WWxxOrZhdSFluUuyTV WHqg== X-Gm-Message-State: APjAAAUWy1UGKi6xjmC/GvNLNQC7BjX8yYRKoopspZ6Dgsyxt7J+OaTF cQbWKfmSQxsGmkQ0WVOedsciUaCPTQhFaWNLsmTSHg== X-Received: by 2002:a9d:30c8:: with SMTP id r8mr5418112otg.363.1574321547958; Wed, 20 Nov 2019 23:32:27 -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:32:16 -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 11:23 PM Dan Williams wrote: > > 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? Why not just swap the parent child relationship in the PREFLUSH case?