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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 315A9C56201 for ; Tue, 27 Oct 2020 10:32:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DFDAB20704 for ; Tue, 27 Oct 2020 10:32:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2898312AbgJ0KcZ (ORCPT ); Tue, 27 Oct 2020 06:32:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:47580 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2898272AbgJ0KbT (ORCPT ); Tue, 27 Oct 2020 06:31:19 -0400 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 1311CB2A4; Tue, 27 Oct 2020 10:31:18 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 2F56FDA6E2; Tue, 27 Oct 2020 11:29:44 +0100 (CET) Date: Tue, 27 Oct 2020 11:29:44 +0100 From: David Sterba To: Qu Wenruo Cc: linux-btrfs@vger.kernel.org Subject: Re: [PATCH v4 13/68] btrfs: extent_io: remove the extent_start/extent_len for end_bio_extent_readpage() Message-ID: <20201027102944.GZ6756@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Qu Wenruo , linux-btrfs@vger.kernel.org References: <20201021062554.68132-1-wqu@suse.com> <20201021062554.68132-14-wqu@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201021062554.68132-14-wqu@suse.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, Oct 21, 2020 at 02:24:59PM +0800, Qu Wenruo wrote: > In end_bio_extent_readpage() we had a strange dance around > extent_start/extent_len. > > The truth is, no matter what we're doing using those two variable, the > end result is just the same, clear the EXTENT_LOCKED bit and if needed > set the EXTENT_UPTODATE bit for the io_tree. > > This doesn't need the complex dance, we can do it pretty easily by just > calling endio_readpage_release_extent() for each bvec. > > This greatly streamlines the code. Yes it does, the old code is a series of conditions and new code is just one call but it's hard to see why this is correct. Can you please write some guidance, what are the invariants or how does the logic simplify? What you write above is a summary but for review I'd need something to follow so I don't have to spend too much time reading just this patch. Thanks.