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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E372C7EE2A for ; Wed, 31 May 2023 22:37:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230313AbjEaWhI (ORCPT ); Wed, 31 May 2023 18:37:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230360AbjEaWhH (ORCPT ); Wed, 31 May 2023 18:37:07 -0400 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1B7E192 for ; Wed, 31 May 2023 15:37:02 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3980f2df1e7so45842b6e.1 for ; Wed, 31 May 2023 15:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1685572622; x=1688164622; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=n3rg9Z09BIl1aIQXz+8gKGwERErjA3Juhruo9wqB2U8=; b=wiX6dI4YQSE++dSI7EaUMDXFauekYMtpXk1nx5uvMyo25lrfQV5e1AHiqUl7vtZsLM IMsq1Z5rdgpxryXDQhmnhU6BFy28pl/Iq9YtSyYwXYAcruYkWNkt+idLzDGSUr3FKl5P 71TZQmlrc+8IX5Yr3GC2L31c13tTWeaseGd8GHnF4nTP4gHfGL9GdiqTtVrRnTBPX75w rNqYxEQM0IHHwuhf+2DOFuAeL1Rj0RWSYjbBRij29aY9ImveoAP+ZDW+DAQgL+Nrskc1 zy8HdL5xcRs5rA3RogSXnzYu4aaVp7d7YXAaBJhIgs7D1bBPAkB/rkpyaOArHbaD1136 cQVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685572622; x=1688164622; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=n3rg9Z09BIl1aIQXz+8gKGwERErjA3Juhruo9wqB2U8=; b=MjItIIYm+9On4pX8jpSB7kf+yfscpYDkEqlG04TX6Wv45wjG5s3lOgqiziLwOf0Se0 1vnNHI0YbyiyK1D/w6xq6MQNzaYkyKOh2HCR8rcEJa1GFYj7z6y0rmBTKBLVRf4JNdsv OGnTDrEpkBTLrrdI6dWioXcPkEMIAeawLBOXKTAz0QpRJxgXtPdU9TEiaPydzZ8yw6eL ZSKNT3RIXed/esIp4b92trOvExH8akhPWrJORNVvUhJ1worxHGLWpW0bYztJOHGn8D9K HKbILzN0g1bzSfRKrm3mElyXfadlSAn7ERjIKSTi/WklUo3SDDszXtqyEtTKq2Ch9saC 9gHA== X-Gm-Message-State: AC+VfDycgOhm8ypiVni+e/DCz+ewb/I7hE6mfB4PntOEaacZlIIxDGOj bhI0mXjWUl0fQH/fz3OqSgCAQQ== X-Google-Smtp-Source: ACHHUZ7R3wjvNkmWSbL60I9ylavOeUTJY88g1+p1PDiLJE+SHWNaI13IUYsVS+xjUDM8kOkAj2iUNQ== X-Received: by 2002:a05:6808:1496:b0:398:2f85:ff7f with SMTP id e22-20020a056808149600b003982f85ff7fmr6512900oiw.50.1685572621938; Wed, 31 May 2023 15:37:01 -0700 (PDT) Received: from dread.disaster.area (pa49-179-0-188.pa.nsw.optusnet.com.au. [49.179.0.188]) by smtp.gmail.com with ESMTPSA id e12-20020a170902784c00b001b034fafaefsm1948337pln.38.2023.05.31.15.37.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 May 2023 15:37:01 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1q4UR9-006HGI-0M; Thu, 01 Jun 2023 08:36:59 +1000 Date: Thu, 1 Jun 2023 08:36:59 +1000 From: Dave Chinner To: Johannes Thumshirn Cc: Jens Axboe , Christoph Hellwig , Hannes Reinecke , Chaitanya Kulkarni , Damien Le Moal , Ming Lei , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, dm-devel@redhat.com, Song Liu , linux-raid@vger.kernel.org, Mike Snitzer , Matthew Wilcox , Dave Kleikamp , jfs-discussion@lists.sourceforge.net, cluster-devel@redhat.com, Bob Peterson , Andreas Gruenbacher , Mikulas Patocka , gouha7@uniontech.com Subject: Re: [PATCH v7 19/20] fs: iomap: use bio_add_folio_nofail where possible Message-ID: References: <58fa893c24c67340a63323f09a179fefdca07f2a.1685532726.git.johannes.thumshirn@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58fa893c24c67340a63323f09a179fefdca07f2a.1685532726.git.johannes.thumshirn@wdc.com> Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, May 31, 2023 at 04:50:42AM -0700, Johannes Thumshirn wrote: > When the iomap buffered-io code can't add a folio to a bio, it allocates a > new bio and adds the folio to that one. This is done using bio_add_folio(), > but doesn't check for errors. > > As adding a folio to a newly created bio can't fail, use the newly > introduced bio_add_folio_nofail() function. > > Reviewed-by: Christoph Hellwig > Reviewed-by: Matthew Wilcox (Oracle) > Signed-off-by: Johannes Thumshirn > --- > fs/iomap/buffered-io.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 063133ec77f4..0edab9deae2a 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -312,7 +312,7 @@ static loff_t iomap_readpage_iter(const struct iomap_iter *iter, > ctx->bio->bi_opf |= REQ_RAHEAD; > ctx->bio->bi_iter.bi_sector = sector; > ctx->bio->bi_end_io = iomap_read_end_io; > - bio_add_folio(ctx->bio, folio, plen, poff); > + bio_add_folio_nofail(ctx->bio, folio, plen, poff); > } > > done: > @@ -539,7 +539,7 @@ static int iomap_read_folio_sync(loff_t block_start, struct folio *folio, > > bio_init(&bio, iomap->bdev, &bvec, 1, REQ_OP_READ); > bio.bi_iter.bi_sector = iomap_sector(iomap, block_start); > - bio_add_folio(&bio, folio, plen, poff); > + bio_add_folio_nofail(&bio, folio, plen, poff); > return submit_bio_wait(&bio); > } > > @@ -1582,7 +1582,7 @@ iomap_add_to_ioend(struct inode *inode, loff_t pos, struct folio *folio, > > if (!bio_add_folio(wpc->ioend->io_bio, folio, len, poff)) { > wpc->ioend->io_bio = iomap_chain_bio(wpc->ioend->io_bio); > - bio_add_folio(wpc->ioend->io_bio, folio, len, poff); > + bio_add_folio_nofail(wpc->ioend->io_bio, folio, len, poff); > } We lose adjacent page merging with this change. We've had performance regressions in the past that have been attributed to either the page allocator not handing out sequential adjacent pages for sequential writes and/or bios not merging adjacent pages. Some hardware is much more performant when it only has to do a single large DMA instead of (potentially) hundreds of single page DMAs for the same amount of data... What performance regression testing has been done on this change? -Dave. -- Dave Chinner david@fromorbit.com