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 A79CAC46CD2 for ; Wed, 24 Jan 2024 05:43:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E84C6B0082; Wed, 24 Jan 2024 00:43:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 299246B0083; Wed, 24 Jan 2024 00:43:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1881B6B0085; Wed, 24 Jan 2024 00:43:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0A9216B0082 for ; Wed, 24 Jan 2024 00:43:51 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BE00880C89 for ; Wed, 24 Jan 2024 05:43:50 +0000 (UTC) X-FDA: 81713113020.17.6849FA7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id BDEE7140012 for ; Wed, 24 Jan 2024 05:43:48 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lok+F+da; dmarc=none; spf=none (imf23.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=1706075029; a=rsa-sha256; cv=none; b=nuO6pTKg0NmoCOr2unPEWwnVs97IrllbFdNqwKXxs9J5II1+Ibdb7xc2SRsSfLNww7kIz6 W/p9J8Jb9oUxygKceed4MXf5eokNbQTziJ9Cr1hJnFKWwu4/szfjWtpA/6WpJRpdGYWYuk h/V5UFmA8GbDGRl1s2BWn5OBdoDDaLA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lok+F+da; dmarc=none; spf=none (imf23.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=1706075029; 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=nTzX0ljJVXQ+O0UX99CLGNwm7GzGUiVuz7AM8TsDxNk=; b=zr1SeyCMptKD+67NCKmHyrtq5Dn6HXgbrLut5A5GoKxNE5llmj9cRdVo8aLGm2VTqeLcQR EE3IAvVEeHoUPOmMuOexu5M2L3jPbTVPcjYbeaWw5pNRTIB5Uqr2bCIapCWWAHz2lxMOkn SNj/yxOdgbltTrqmb06FdoB3xzEHll8= 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=nTzX0ljJVXQ+O0UX99CLGNwm7GzGUiVuz7AM8TsDxNk=; b=lok+F+daa3q9v83La6MUdJ/nOc hzI+A/DJNcIodVcDbnyRV/wTc7r4V0vA2wUdIFfC3KwJDRW7bbNJZwpehRRMHtljUj1p0v8suiNCt zmJxF3PJsxRkK1dJBYFr4JxefUXs6ImIJufGHjul1qqoRkvv9ZLIYOznp5x9zPyLJIIsFKhc2MaFh cpu7DhvmExwCeCQy8hh5Nq5D2iU5vYtWzlXCX8u1guVZON8d7BK4P2LVsFW/GUr+O6M8X+cV+Hdwh 12JLYAtowIOe9PErdJd1v96MBMNynj1MLrqqIn8JctYTdM92GGrgsHFyAVqCBUFzR6xqup2nqPcFH 7ZuvslLA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rSW39-00000005Yax-0BJE; Wed, 24 Jan 2024 05:43:47 +0000 Date: Wed, 24 Jan 2024 05:43:46 +0000 From: Matthew Wilcox To: Qu Wenruo Cc: Qu Wenruo , linux-btrfs@vger.kernel.org, Linux Memory Management List Subject: Re: [PATCH RFC 0/2] btrfs: defrag: further preparation for multi-page sector size Message-ID: References: <45066165-3d2d-4026-87d3-2cfe3369a86b@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45066165-3d2d-4026-87d3-2cfe3369a86b@gmx.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BDEE7140012 X-Stat-Signature: dxqyoeem8gmecjrutk8oubxknkzz7bqd X-HE-Tag: 1706075028-839673 X-HE-Meta: U2FsdGVkX18jfAchzN7W+GsHF/z1GNNPvscqvcLcaYc0GC8bZySgb2O1FE1KhTdcs3v5v+U0ei3JmjzXDHVuh5NBU382XN6D/bVb+DjaI3bfwV5MGjR6tyfUHYTOiGsV4fIWvV8ldUyfQt4gkWbKCEgBX82gVoV9PNJ2lgYkNNZGzcG2AG6/0yV6fcaECvQ2CJRI9IeJopk0qKC0YT2Ung4HHLMnD2UGUr0cUdQ8qoUPSavpT2hMuDR3AcM/y+1pkGlyPLB/upJfTiO/4mKhEH5qa7LvBz+9r0yx0VV+Mgc8zbM0LRCo/Waqz2nvB/yKwQZbKVRfhrMVsvU6hwerLTriNBi2Tkx28RFwS4n6Xb8go3hTqwrwUfc1g4lQrJLuqxsahJqy82GZwMYfb5g4kVY0FmQbZo+HfZ9XPvYg9y71j7vtgW24btR/3JmBxh3N+2DwCEVF7NWciIdmY0TNGA8uYqjI1uvD1SuXecmsfH2TvEgLLHdNzHE6L7PmoOfdid8lhdVysi/7/0G5V2erd4qVCR3Kh7jQPT2ga8FfpNrhKrb8UmiqvdRrOVYaVQDqbiUeUZIbjPDUy+KpQncBsJ2ezX7LqE0yh5jwqVfm53B59KCk/oinTnGHBcKJOVyU6EmFp27jSPa48HANRo52B4yLuFw+AZWAEWniUX15NoHNW8TvT1BStUsngsmoIe4qldwbIb3xx8km/i1m5aSPjXGV/hibtrkMaR/QzVD46Vv4udcJXRVDHcc3+7uEt5Bhg8QrHqxD4p/ndw9CCrD6oF79APNDYFozN094GN99UYoBOuT3vHpzOC+BnpgYrRFGmTNlCYip8M3tMGt9LKwYatCOnAux6kAp8dSf3tYT9Fop9fkSrPyquWmmQM+WeMa53YHBsBl0IOfucA4sV2YILhpXX8I9rPJdYumoBuM1brOwtPPbIqDp9EeP6XJ4YD9mppDqyKqliXmO7Ez7qaF +BHHaIXg PJ2TIn0b2H2+u+jQ6oqsiyW7kXmUaa1QhGP5TKlqrrbCye3P7m7PwpM6rNw4taPSvAojJwoVi1KJqG88bN5a6i+TIN19sKdgBVS7hscfmvq5rKaGJn0fjm8z6Px91GN6k1y42g2XXqDX9R5o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Wed, Jan 24, 2024 at 03:57:39PM +1030, Qu Wenruo wrote: > > > On 2024/1/24 15:18, Matthew Wilcox wrote: > > On Wed, Jan 24, 2024 at 02:33:22PM +1030, Qu Wenruo wrote: > > > I'm pretty sure we would have some filesystems go utilizing larger folios to > > > implement their multi-page block size support. > > > > > > Thus in that case, can we have an interface change to make all folio > > > versions of filemap_*() to accept a file offset instead of page index? > > > > You're confused. There's no change needed to the filemap API to support > > large folios used by large block sizes. Quite possibly more of btrfs > > is confused, but it's really very simple. index == pos / PAGE_SIZE. > > That's all. Even if you have a 64kB block size device on a 4kB PAGE_SIZE > > machine. > > Yes, I understand that filemap API is always working on PAGE_SHIFTed index. OK, good. > The concern is, (hopefully) with more fses going to utilized large > folios, there would be two shifts. > > One folio shift (ilog2(blocksize)), one PAGE_SHIFT for filemap interfaces. Don't shift the file position by the folio_shift(). You want to support large(r) folios _and_ large blocksizes at the same time. ie 64kB might be the block size, but all that would mean would be that folio_shift() would be at least 16. It might be 17, 18 or 21 (for a THP). Filesystems already have to deal with different PAGE_SIZE, SECTOR_SIZE, fsblock size and LBA size. Folios aren't making things any worse here (they're also not making anything better in this area, but I never claimed they would). btrfs is slightly unusual in that it defined PAGE_SIZE and fsblock size to be the same (and then had to deal with the consequences of arm64/x86 interoperability later). But most filesystems have pretty good separation of the four concepts.