From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21933C432C0 for ; Thu, 21 Nov 2019 07:24:04 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E6BA22089D for ; Thu, 21 Nov 2019 07:24:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="Aamx4FNU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6BA22089D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from new-ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 5F8DC100DC2BD; Wed, 20 Nov 2019 23:24:40 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::344; helo=mail-ot1-x344.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9B289100DC2BA for ; Wed, 20 Nov 2019 23:24:36 -0800 (PST) Received: by mail-ot1-x344.google.com with SMTP id b16so2045164otk.9 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=DBuiD+/iNv83tXWrUG4zNgR6dw+cgr44/ivl+skXkdo8LHArLxg9TV2voR3eX9/kJl 5FFHSfRr8Mvpmt2LGqFc9HQFkicZ7Ny6rCyQNic34gYW4iZzDhbqNpMWTKbpQN4/tlQJ KbXbGbh2UWVl4iqBk8EWfBG1RBnWXwmyzu6+d237sld792bS4fk6Z3U0PqSAYALjEVqV xj6W4A8wnp4fwiwkpmQhjOrlok+J0rgxU7mC+9JVdOTbfbLH0m8Ej95hqDXsRZXCssST 42/C5aenYfbJ836V6c9eVVVWnTAaKsFTSnipfPNzH933oBjbCTmE8qBI5cEO+MgrIIKi IxaQ== X-Gm-Message-State: APjAAAWyVaXxjSIKL5yC8QHSw4SypR8MJ4V3cUAnpycSbwt3acHELuUO eLaVINM+7IJFdG9YjvCA/fA+veVe+xtoiIY3TWsyPw== X-Google-Smtp-Source: APXvYqws9XkJQSLixl8sCxSf8KR7piXMbSGOHYMZNFTKMUrilxcOOTe8eFSPb/y5vtMhiXzk8SHG7lti/eziN7V7EtQ= 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 Message-ID-Hash: 6362S4NL5GIBMBH4GD7YRHIVG6AUXK74 X-Message-ID-Hash: 6362S4NL5GIBMBH4GD7YRHIVG6AUXK74 X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: linux-nvdimm , Linux Kernel Mailing List , Linux ACPI , "Rafael J. Wysocki" , Len Brown X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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? _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org