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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CD6BC3600C for ; Thu, 3 Apr 2025 17:44:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 939A4280006; Thu, 3 Apr 2025 13:44:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E9B5280005; Thu, 3 Apr 2025 13:44:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D998280006; Thu, 3 Apr 2025 13:44:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5EEDB280005 for ; Thu, 3 Apr 2025 13:44:25 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1D3EF58B55 for ; Thu, 3 Apr 2025 17:44:26 +0000 (UTC) X-FDA: 83293456932.29.18CD52A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id 7CC7A40009 for ; Thu, 3 Apr 2025 17:44:24 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="nl/vq4hP"; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743702264; a=rsa-sha256; cv=none; b=TAr6AH6l4JC8BUnVFzUqLn/tZlY9g8bovdHwQ5tu+6Pt+/NUbKdixMXZOo5f8wks3SYtA5 xHchHtL5Vm9fHEGr9nOM4R8KKLTRx33J3lpcPgHOBKXf/j+ONdhA4Wburx/HzgUhIATTVX A+vZHDW1aLbciaIqYu7tr8WySHZFKmk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="nl/vq4hP"; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743702264; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5bCE/e2+eVXHTwCCmYdkChzX3931MOPxX+eV7bSag/U=; b=W2MU2K0asrL83ghyn4YPG1g0TyG7F2jnrB33kbBnxSXlmdQLf8y22gqhx8svpfDA4lb+ui IUOc9887pLc8MjjzWyUhVpnjU3Heu6DZLMjRxdNHnNX1LlaphIsteSb2gOBdhKWp+OtviG A9QLpUCvXsVAzTp9c2Z/hXmJUh0ICxI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=5bCE/e2+eVXHTwCCmYdkChzX3931MOPxX+eV7bSag/U=; b=nl/vq4hPPV2slo8lQS9KTGLAhW 6HT134e/y+NZ35rY3CdmUXCSkbL80OApd2x+j6ZZdgRWFNVvK+Oo7UKFGHIA+Oa806RrDdDmAb3bV izWJCkr2/Of7CnP3qDjiTLx+h8IBMTVhDYyeVgJaVZ0jLmK6uf4URDQvcX+vym6kRYEFRgybeh0hQ w+XUonev7HTQeJOpUVPYihT/xxjQD60dOfBP/1tb3PmewCtnuRPQxfL+6KSruHCKZzAWT6wlrs60U SfvbpVqqbcmErdNuypbivLXijOP3Wsk6g9/2vCP/Op8cpATSj62osNgmmHqRyweRtPSMw6Eh9rTXq vJqZSuTg==; Received: from willy by casper.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1u0Oc2-0000000DPFq-29E2; Thu, 03 Apr 2025 17:44:22 +0000 Date: Thu, 3 Apr 2025 18:44:22 +0100 From: Matthew Wilcox To: Qu Wenruo Cc: Linux Memory Management List , "linux-block@vger.kernel.org" , linux-fsdevel@vger.kernel.org, linux-btrfs Subject: Re: Proper way to copy de-compressed data into a bio, in folio style? Message-ID: References: <17517804-1c6b-4b96-a608-8c3d80e5f6dd@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17517804-1c6b-4b96-a608-8c3d80e5f6dd@gmx.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7CC7A40009 X-Stat-Signature: xwd4edafifkd8t6xprsnwunosyajh9js X-Rspam-User: X-HE-Tag: 1743702264-629480 X-HE-Meta: U2FsdGVkX1/yHaWK2HWI+VoiSv+cx3auR/P/4r4P0MEM3sOL2g8u7BcanaQ/7uu0vYU2jcNfmyLY8dEGgXV8GHcARwWoJyvIEgOZHbtTF6wsZZTLx+U3WJjt4ZDxG+HQ98Dm6xVDvJpdDtd1/SC05bUdZn6jC6HCYKAxQa9T1oRGeh3rvxXn2XIh3yxutgvyewhneItgJExfSAumDkj3NMf1j9JD8X5AHDpSDNK4p8JkkddZYlbl6+k0jdHuHYXhfH66TKY6TAn3vtIw5aLROQWPWLCY3UG5Hel+4t2ZD8EihnX/fTy6FN3N0fn2sRf+RTp37N0JUzL8VyWo5oEv95igKZajLqYYFclyl5Tv+FdypBjQK73G4TnPGAeIdpnG+xyt1HRcDOrNhJBuAOQN97fMnt0wb7s+MEF6bxoAV2OepAFy92UREHIWi/VaWTegkX3psdd9Vc8jOJqSzfP9Ur74u1xKTu1pcxW7ExZOpI6nr+bAVUfx6LnhYLPqAps/fNXLfjDVD/z+zHL+Ks51BDu6Wk1musJLK2V23jc9owHOqJEyoVXDQirT/RsUeIvCGKbh/zMK1rORBVsxvxkXpuzBQ/tc6AZ1KhMPXeczE9hSwnW5aPGfbOlMYL7su22SUs4TXxWw6Sc7/IIX2+I6T+C0aa+ZtSYqof+ZZO1U5+YFLh8JBWzGBzu91MthHhf7EliyBMBgoc5zmCmS8e9j1tWOyiYRYz0sEhsMZITavMmH+RW+2bzyAQ1xGtp8FQEIJ0FArw+YwXKXO+7wyOlK79pfzedkGFFKiIYVwVhSp3WUcv7DqciOph9CO7mbvTNmDR2pY57V6qcX4xWM9XETWLBdJtIFWO0DQfPst3AQ9wVdfqawsOXiuzC1w/qalDew6kvbu7hrxuiwJoJepsKGsVTAl5VyFDNUfuTEB/+hnMrl97pXGI5sRoo5oJWVg2KsFRom+ezciqXghhjHZU2 wIu/Ctei 6Qz+m7WRV4sesIqwEUMoPX2Y6594Ph3eHCAz6rC2GFneR4QWio5Ez/HlQAoFIZdXbdss4dXqjdfuV61JFZIHV3fKG5UMK33Kh+c7ck6gq7GOKlz2r6ur90MhzxcnsYwPLnGAF0u2MGUrFEnynbNqEaZnuQ7LGEIG8Z6+ep8NVqdc+05ZNotle7LblUGuEUOZE8YAcwPGVYKRvILthJdk38xRpO8Eqg7qMPJckZvwac2ZUa7IESJMT1cXHLsm1ERTiGwUzgQatB1UIzO+2IukZ4KbM7xlN5Qm/r3U0MsEpc+UIbcVyRp4gbgTPVg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000979, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Mar 31, 2025 at 06:45:10PM +1030, Qu Wenruo wrote: > Hi, > > The seemingly easy question has some very interesting extra requirements: > > 1. The bio contains contig file map folios > The folios may be large. > So page_offset() on bv_page (using single-page bvec) is no longer > reliable, one has to call page_pgoff() instead. page_offset() is on my hitlist. It actually is correct now (commit 12851bd921d4) but it's on its way out. Don't use bv_page. > 2. The data may not cover the bio range > So we need some range comparison and skip if the data range doesn't > cover the bio range. I have no idea what this means. > 3. The bio may have been advanced > E.g. previous de-compressed range has been copied, but the remaining > part still needs to be fulfilled. > > And we need to use the bv_page's file offset to calculate the real > beginning of the range to copy. > > The current btrfs code is doing single page bvec iteration, and handling > point 2 and 3 well. > (btrfs_decompress_buf2page() in fs/btrfs/compression.c) > > Point 1 was not causing problem until the incoming large data folio > support, and can be easily fixed with page_pgoff() convertion. > > > But since we're here, I'm also wondering can we do it better with a > folio or multi-page bvec way? > > The current folio bio iteration helper can only start from the beginning > of a bio (bio_for_each_folio_all() and bio_first_folio()), thus it's not > a good fit for point 3. > > On the other hand, I'm having some internal code to convert a bio_vec > into a folio and offset inside the folio already. > Thus I'm wondering can we provide something like bio_for_each_folio()? > Or is it too niche that only certain fs can benefit from? I don't understand your requirements. but doing something different that fills in a folio_iter along the lines of bio_for_each_folio_all() would make sense.