Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5948775yba; Thu, 11 Apr 2019 08:58:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqxwdKbxqwkEQgIhmDcwgTBc2kw/ggzCa5q+gbGA5ri7T+1d6d/N7XTjnyiAb346a+jlPdTV X-Received: by 2002:a17:902:7d81:: with SMTP id a1mr50928049plm.202.1554998314212; Thu, 11 Apr 2019 08:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554998314; cv=none; d=google.com; s=arc-20160816; b=bmYH8UCeb5+Ba+EENtPq/p7uFqL5u0aDnLeAu0PXjNhJRLFBE/1GNxLcd2YqegRhGy JNwexYuee8el5CLqhjeypVW9zA7E99HKBLwgdWmfiWe3mFFQ088aanoQlWZck0PZmpaM VvqpzIyREE9igSRVzCJAsgPKKpkWUirXbIiLen+b/Pyhkv6PHu67jqXdrqtgtZbQUsie VffRHzXK/gwqGWB+IdpyufNf8B2K/w0+hSk1Oa2Fg10nptAHqmvEJZNV7/Mo6CMJ56fJ UfBTSJbT1/zaLOgS0Kv1jt+a2xhqLq7ZsBzJ6XcePa/mG78dyi4yoIF/vvXAtY3qUaCz Ygag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date; bh=/iJ3oA2ASAj66949d1oE3ZCovhox9JrS/cKo66BROQk=; b=qgLLHU1viAfJ9nwvCGhCifHm5ZOIS0GxRSe04g+uunrPW0CPtMVZAz0bR1x+mWkj9H t30Djq8kiKQYFP2hW/TjTeUWMcKIn2MTHxtNSyL5i5vU5T4ui1WyUGAV1ncm0OH/4P7V TKBNWUUVWAYD4npzW0JzFe8YjFSUEav930T7Bu5wT3kNLMYqTnYv6DaEDcCe/nc3fz05 +qzLOBjukVETJWcSg832HhXbt48C9F7rDhol9YD+Wiaa7LU4OstjMtwCeWTpfTv/+Xai cajE7yy6stfQGUpo38PuJQB9kM8d4Hl/Oqxh4igtkD9nLOk3f7e3svhSxaPOrcXB7hey okzw== ARC-Authentication-Results: i=1; mx.google.com; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f66si996658plb.281.2019.04.11.08.58.17; Thu, 11 Apr 2019 08:58:34 -0700 (PDT) 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; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726777AbfDKP5l (ORCPT + 99 others); Thu, 11 Apr 2019 11:57:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52658 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726145AbfDKP5l (ORCPT ); Thu, 11 Apr 2019 11:57:41 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D429D30671F5; Thu, 11 Apr 2019 15:57:39 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B249B69183; Thu, 11 Apr 2019 15:57:39 +0000 (UTC) Received: from zmail21.collab.prod.int.phx2.redhat.com (zmail21.collab.prod.int.phx2.redhat.com [10.5.83.24]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 17B693FB10; Thu, 11 Apr 2019 15:57:39 +0000 (UTC) Date: Thu, 11 Apr 2019 11:57:38 -0400 (EDT) From: Pankaj Gupta To: Dan Williams Cc: cohuck@redhat.com, Jan Kara , KVM list , "Michael S. Tsirkin" , Jason Wang , david , Qemu Developers , virtualization@lists.linux-foundation.org, Andreas Dilger , Ross Zwisler , Andrea Arcangeli , Dave Jiang , linux-nvdimm , Vishal L Verma , David Hildenbrand , Matthew Wilcox , Christoph Hellwig , Linux ACPI , jmoyer , linux-ext4 , Len Brown , kilobyte@angband.pl, Rik van Riel , yuval shaia , Stefan Hajnoczi , Paolo Bonzini , lcapitulino@redhat.com, Kevin Wolf , Nitesh Narayan Lal , Theodore Ts'o , Xiao Guangrong , "Darrick J. Wong" , "Rafael J. Wysocki" , Linux Kernel Mailing List , linux-xfs , linux-fsdevel , Igor Mammedov Message-ID: <1463291806.21158433.1554998258746.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20190410040826.24371-1-pagupta@redhat.com> <20190410040826.24371-2-pagupta@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 1/6] libnvdimm: nd_region flush callback support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.116.71, 10.4.195.2] Thread-Topic: libnvdimm: nd_region flush callback support Thread-Index: GJ8qWIgyQ5yOMTJqnF06RrwSs6tgyQ== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Thu, 11 Apr 2019 15:57:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > This patch adds functionality to perform flush from guest > > to host over VIRTIO. We are registering a callback based > > on 'nd_region' type. virtio_pmem driver requires this special > > flush function. For rest of the region types we are registering > > existing flush function. Report error returned by host fsync > > failure to userspace. > > > > This also handles asynchronous flush requests from the block layer > > by creating a child bio and chaining it with parent bio. > > > > Signed-off-by: Pankaj Gupta > > ---bio_chain Dan williams > [..] > > diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c > > index b4ef7d9ff22e..fb1041ab32a6 100644 > > --- a/drivers/nvdimm/region_devs.c > > +++ b/drivers/nvdimm/region_devs.c > > @@ -295,7 +295,9 @@ static ssize_t deep_flush_store(struct device *dev, > > struct device_attribute *att > > return rc; > > if (!flush) > > return -EINVAL; > > - nvdimm_flush(nd_region); > > + rc = nvdimm_flush(nd_region, NULL, false); > > + if (rc) > > + return rc; > > > > return len; > > } > > @@ -1085,6 +1087,11 @@ static struct nd_region *nd_region_create(struct > > nvdimm_bus *nvdimm_bus, > > dev->of_node = ndr_desc->of_node; > > nd_region->ndr_size = resource_size(ndr_desc->res); > > nd_region->ndr_start = ndr_desc->res->start; > > + if (ndr_desc->flush) > > + nd_region->flush = ndr_desc->flush; > > + else > > + nd_region->flush = generic_nvdimm_flush; > > + > > nd_device_register(dev); > > > > return nd_region; > > @@ -1125,11 +1132,36 @@ struct nd_region > > *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus, > > } > > EXPORT_SYMBOL_GPL(nvdimm_volatile_region_create); > > > > +int nvdimm_flush(struct nd_region *nd_region, struct bio *bio, bool async) > > +{ > > I don't quite see the point of the 'async' argument. All the usages of > this routine are either > > nvdimm_flush(nd_region, bio, true) > ...or: > nvdimm_flush(nd_region, NULL, false) Agree. > > ...so why not gate async behavior on the presence of the 'bio' argument? Sure. > > > > + int rc = 0; > > + > > + /* Create child bio for asynchronous flush and chain with > > + * parent bio. Otherwise directly call nd_region flush. > > + */ > > + if (async && bio->bi_iter.bi_sector != -1) { > > + > > + struct bio *child = bio_alloc(GFP_ATOMIC, 0); > > + > > + if (!child) > > + return -ENOMEM; > > + bio_copy_dev(child, bio); > > + child->bi_opf = REQ_PREFLUSH; > > + child->bi_iter.bi_sector = -1; > > + bio_chain(child, bio); > > + submit_bio(child); > > I understand how this works, but it's a bit too "magical" for my > taste. I would prefer that all flush implementations take an optional > 'bio' argument rather than rely on the make_request implementation to > stash the bio away on a driver specific list. I did this to make use of "bio_chain" for chaining child bio for async flush suggested [1]. Are you saying to remove this and just call "flush" based on bio argument? Or I implemented the 'bio_chain' request entirely wrong? [1] https://lkml.org/lkml/2018/9/27/1028 > > > + } else { > > + if (nd_region->flush(nd_region)) > > + rc = -EIO; > > Given the common case wants to be fast and synchronous I think we > should try to avoid retpoline overhead by default. So something like > this: > > if (nd_region->flush == generic_nvdimm_flush) > rc = generic_nvdimm_flush(...); Sure. Thanks, Pankaj > >