Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp894465pxb; Thu, 28 Jan 2021 03:04:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJymlNnPK8wl78lNuaH+gTd7fD1przL/yNSfBDBb94/1iN3Jtxf0ffqLLAMJCpaBjL0uC5A7 X-Received: by 2002:a17:906:3c04:: with SMTP id h4mr10595131ejg.51.1611831868293; Thu, 28 Jan 2021 03:04:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611831868; cv=none; d=google.com; s=arc-20160816; b=ec8ogQgWwjJzbMHLjhW1mLzqP/XZ5fqmb1Cnb2PqvRo7sH/9B/oDYnSKmkKBD7aNXu iRFF/+8JES3wtDhM/Han3VapEvD36sL51zekfWpZvW7AL5v9ALW2Y2RI0bF7fFz+BHw8 H6orvkxzBaCH1WvbZjzYakGPN1kTBVSsjVxOrE8nkal3E0xgmN1yKf/qEBALjDz/S+aC p6MPxKJdrRZt/hv6mR7/mTsOVm+GUP6WaWaU5jXs2dgp8bQAiTZSjGudyuqEDzm5zAJa t4K31OSYkZb1X5tWRron24ZgzsNVH8ZT/BJuzluvtK2tnBroB+ddtOTibSVjz104Fzg5 MLBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date; bh=4Iep4ZHnLKg6nGuDUkYZJ6zCCW64vGDxemladRWCa5k=; b=0Rzdt9hKNYrp6kCsZ6EZ2CqHd5vtyO/zJ4wTY/h5stoXbb9xNyOgU32Bvue2xksk7e FHCnOxkzB+kfTihOlNG7PRe2lLdhZ0rOiKz8HpfnxeFOuRtIgBBzMhE46KFpCIV1k5sQ of7cSul0OXjNM8N3mgIA2SvFNDfi0zPlUlFrsHLuKJwXZO6LHp+TuNE30ZPLC8PRLMmy 3efDEo257BwqYfblaBj4GQ0Ht4G0tZzDDuN7YQCJDmkX/ayPk2EjhhH7EqHn2rmjGm9a MMhvAVnag11Qb+DJbXvN+BtIWOzxk8Ic5r6LgMZ8AaVHihadH1RXNn/xhxqe/lkKkmqg XSAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x20si3225910edl.75.2021.01.28.03.04.02; Thu, 28 Jan 2021 03:04:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229830AbhA1LDC (ORCPT + 99 others); Thu, 28 Jan 2021 06:03:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:46576 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229732AbhA1LDB (ORCPT ); Thu, 28 Jan 2021 06:03:01 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C7EC1ABC4; Thu, 28 Jan 2021 11:02:18 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 0C8B2DA7D9; Thu, 28 Jan 2021 12:00:30 +0100 (CET) Date: Thu, 28 Jan 2021 12:00:30 +0100 From: David Sterba To: Filipe Manana Cc: Michal Rostecki , Chris Mason , Josef Bacik , David Sterba , linux-btrfs , Linux Kernel Mailing List , Michal Rostecki , nborisov@suse.com Subject: Re: [PATCH v2] btrfs: Avoid calling btrfs_get_chunk_map() twice Message-ID: <20210128110030.GJ1993@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Filipe Manana , Michal Rostecki , Chris Mason , Josef Bacik , David Sterba , linux-btrfs , Linux Kernel Mailing List , Michal Rostecki , nborisov@suse.com References: <20210127135728.30276-1-mrostecki@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 28, 2021 at 10:38:45AM +0000, Filipe Manana wrote: > On Thu, Jan 28, 2021 at 12:01 AM Michal Rostecki wrote: > > > > From: Michal Rostecki > > > > Before this change, the btrfs_get_io_geometry() function was calling > > btrfs_get_chunk_map() to get the extent mapping, necessary for > > calculating the I/O geometry. It was using that extent mapping only > > internally and freeing the pointer after its execution. > > > > That resulted in calling btrfs_get_chunk_map() de facto twice by the > > __btrfs_map_block() function. It was calling btrfs_get_io_geometry() > > first and then calling btrfs_get_chunk_map() directly to get the extent > > mapping, used by the rest of the function. > > > > This change fixes that by passing the extent mapping to the > > btrfs_get_io_geometry() function as an argument. > > > > v2: > > When btrfs_get_chunk_map() returns an error in btrfs_submit_direct(): > > - Use errno_to_blk_status(PTR_ERR(em)) as the status > > - Set em to NULL > > > > Signed-off-by: Michal Rostecki > > Reviewed-by: Filipe Manana > > I think this is a fine optimization. > For very large filesystems, i.e. several thousands of allocated > chunks, not only this avoids searching two times the rbtree, > saving time, it may also help reducing contention on the lock that > protects the tree - thinking of writeback starting for multiple > inodes, > other tasks allocating or removing chunks, and anything else that > requires access to the rbtree. This should answer Nikolay's concerns if shifting around the parameters is worth it. Caching values that could be expensive to read makes sense to me and it's not that intrusive in the code. I'll add your analysis to the changelog and incorporate the fixups that Nikolay suggested in v1. Thanks.