Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4044038ybg; Tue, 29 Oct 2019 01:01:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxi1rz2IXfci+fisQ3hKOySrUaij9/n+xURBUUmaVuDT8TDf8TckQml9naQqcdkJ2dA3GJa X-Received: by 2002:a50:84e9:: with SMTP id 96mr23980196edq.182.1572336104747; Tue, 29 Oct 2019 01:01:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572336104; cv=none; d=google.com; s=arc-20160816; b=oBK3+lxS4WDAJBMOa5WE7AQmN7PebE7QNi43fqJ7XkI8tZiuwCBurimQEuD700SPuk rABFDtNBIAL8YmH2nWD3qYFMN811BoITowoSxufAwUSpsSB/R3qGNk7Bzm7n1/pXC/ZZ ps9gSd9djG/PIiPyNvYd/+0UPEIQQffUveBZMtmTPstjfi9YK3z16e8Eb1XPnywcZGNO h3OSocxVIWIOf0jNpv8Mgi2MY546yZPtOe2CpZspl0NlDAdSkTSy2lujf5PQyey+x86+ z2mDhIyrys60+LgIqNVefvUgs6rrdwN5+KT5uoo36x+peD585XMQMTdt33NQ9Kj+7zDF qeSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=EimkoXmuYD2zCXt4Y3UDa6WqWMAHkf9oWaoRIKTkjI0=; b=0cXzRoPxNhOTXv+kmJxCF5oEfo6mZG6lBfv32ioMsyGwuTaSKWmK8ni5kW/cQxeFOk 9Ho9YCY8DxuoTHENOKvQEyMjEZ+O4kaFO6AE0c3tdJ3QIMdjB80Wv9EJkhMDNrbVJ1fq fdAI6JF9Iy3I4S3mMCbst+UU/TB1CgNH+xZ3Hd29bp0oHzrYtlQsRY63aNB1I4RqQinH UDFh7Z+C2bPumTi8tuWjAK5LPASx199PQ3urC4ozZQ6mqn6rUoaWTX6c55HmJ7HxwHFc tMkgRqxqZa/94cZhHHsjbL17ZdAysR+HUbLvVd8Kd7lbFdTM4xFZ+v59jlH+9SFDbKH2 WN5w== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pg2si7815043ejb.133.2019.10.29.01.01.21; Tue, 29 Oct 2019 01:01:44 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727987AbfJ2Htm (ORCPT + 99 others); Tue, 29 Oct 2019 03:49:42 -0400 Received: from verein.lst.de ([213.95.11.211]:38599 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725776AbfJ2Htm (ORCPT ); Tue, 29 Oct 2019 03:49:42 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 67C9D68AFE; Tue, 29 Oct 2019 08:49:39 +0100 (CET) Date: Tue, 29 Oct 2019 08:49:39 +0100 From: Christoph Hellwig To: Philippe Liard Cc: phillip@squashfs.org.uk, hch@lst.de, linux-kernel@vger.kernel.org, groeck@chromium.org Subject: Re: [PATCH] squashfs: Migrate from ll_rw_block usage to BIO Message-ID: <20191029074939.GA18999@lst.de> References: <20191018010846.186484-1-pliard@google.com> <20191029041013.175636-1-pliard@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191029041013.175636-1-pliard@google.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org FYI, the mail you quoted never made it to me.. On Tue, Oct 29, 2019 at 01:10:13PM +0900, Philippe Liard wrote: > > My admittedly limited understanding is that using BIO indirectly > > requires buffer_head or an alternative including some > > synchronization mechanism at least. What access do you need to synchronize? If you read data into the page cache the page lock provides all synchronization needed. If you just read into decrompression buffers there probably is no need for synchronization at all as each buffer is only accessed by one thread at a time. > > It's true that the bio_{alloc,add_page,submit}() functions don't > > require passing a buffer_head. However because bio_submit() is > > asynchronous AFAICT the client needs to use a synchronization > > mechanism to wait for and notify the completion of the request which > > buffer heads provide. This is achieved respectively by > > wait_on_buffer() and {set,clear}_buffer_uptodate(). submit_bio_wait() is synchronous and takes care of that for you. > > Another dependency on buffer heads is the fact that > > squashfs_read_data() calls into other squashfs functions operating > > on buffer heads outside this file. For example squashfs_decompress() > > operates on a buffer_head array. All the decompressors do is accessing the, and then eventually doing a bh_put. So as a prep patch you can just pass them bio_vecs and keep all the buffer head handling in data.c. Initially that will be a little less efficient as it requires two allocations, but as soon as you kill off the buffer heads it actually becomes much better. > > Given that bio_submit() is asynchronous I'm also not seeing how the > > squashfs_bio_request allocation can be removed? There can be > > multiple BIO requests in flight each needing to carry some context > > used on completion of the request. > > Christoph, do you still think this could be simplified as you > suggested? Yes.