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 3C7D0C46CD2 for ; Wed, 24 Jan 2024 04:48:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AB116B0071; Tue, 23 Jan 2024 23:48:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55B626B007B; Tue, 23 Jan 2024 23:48:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4497A6B007D; Tue, 23 Jan 2024 23:48:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 353F36B0071 for ; Tue, 23 Jan 2024 23:48:17 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C2C1B401DB for ; Wed, 24 Jan 2024 04:48:16 +0000 (UTC) X-FDA: 81712972992.25.952B430 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 9607B1C0005 for ; Wed, 24 Jan 2024 04:48:14 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=d4Tot6wT; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706071695; 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=h364op/wN+x/5kgi8QRjNE+YgsoLEstC8wc8aGpK/4o=; b=N6IjVhumoGLehFW8SBDXbIgjFcdOvisCiOux3kzcCmNfrfEtyFhRord7FBnUN4lE89Scrh HXQ6bU1JR+L5JE0TMt+qroL2C+zDqjBkYho3YkKvOKZdvWDxBEB/fO4/+oTq34l89l5Uzg Q3/mxi8YE4953gRnmf8jrKZ/+y409/A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706071695; a=rsa-sha256; cv=none; b=0Irfpi9T3II0a/6UinWp9wkvPHtHVhl41xEUKqJ6HaHsyaI6sixPObNi/PxHxQBPyG1O2i adnFmtA66Vm1CquO8foxw1ouzAKWtsyqjlLkrbjg2FETLqbGoLOIGVK7eCDmScMFlNr5Gb P1Ud03woIGu005onCMuiorCsEnzMW0k= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=d4Tot6wT; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=h364op/wN+x/5kgi8QRjNE+YgsoLEstC8wc8aGpK/4o=; b=d4Tot6wTR4I8xxBTa9w/8AD8HU hmUaf0l7DiAAFv92nLRz01QIOPF+QrVFFkCtPOT4sX3nIYttSkCwhYkEZRnpe5OuYOmAVXSEuS6OX i6IPSSEmcf/503eiIsqAdJgqysF62DWy3iIiCT0ta97c5/Q0GkWlD5GkiQ6mJGunH6kwVLXRsNP5I B3tOGKSQarNtFsgzuWd8EeraBGJP2XgvB9jiDLlj9I+mSeNohxSd05eekR0v9i589NVtCHmZIOVfI e8DLLtMeFrTbw9+BEQbJbBF0IpU5qDCCprX59sckn+joLPeMHaE7072O/hiPp4niQoOAHNP1ZsfCI YuLDQ21g==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rSVBL-00000005PdC-3Vtv; Wed, 24 Jan 2024 04:48:11 +0000 Date: Wed, 24 Jan 2024 04:48:11 +0000 From: Matthew Wilcox To: Qu Wenruo Cc: 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: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: re4nt6ibh6paikj79wbz198irxa84z74 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9607B1C0005 X-Rspam-User: X-HE-Tag: 1706071694-548527 X-HE-Meta: U2FsdGVkX1+aQvdRSpa+ilCXfYrWT7fe8/Fk4Zg7Qwquos5vrwQ1Jfvx0OXuezJmacuQ3Q+o6fwSCEj/V7UAe2ZfrvBGvn68UUAvpDp7pwzMoWrVOLjdTCxJ8ijyYxKzIJ4r5Lwu2SpltFm35uqXO4o3jjvGFwYGZHch5pPGgzZcwtVk3th2ay+LmSe2QNpj4dCURZCbXvfZ5hgAjV0bjShjhW1b0IzBWcTGG5jZtm0+ajDYvJ5pnccpNu7Cv/AN6W7AXYiMj8JK+Df1aJIwzhoX0EOgZSrgfRaWy4ZWp1JWloV8CdMaXcVVHRqzhSBuLtA6sbuBtfJIMX4LfQwZwMNh66/IR5xY3bqsxeM6+MnSOfl4Gaa9FxYzeIG7t4val98kWxrCggHTR+u3bFZ/mQCZq1H2w345rG/+GuV0o9vTPx60a1TMV1oVljfFh25C4AKCdgMZ9NsBqCzM6QJ3DDRYHNaXwrNFMhhC0tD4aubJTTJ3wLBvcaeXKw7NryGuOHMGspxciZkOT6euGUhynG5Mwqdw1WtqIWD2l7YvKn6K1Funxwi1ToaogJ/O4AhfB24t2uqMZ4NpqFxJsWR/UUIGRC39+XqcuLUnKjAv7sckqcrU6oKkRo6/4UN4+ER5tHAHM2nQZrvf5r70V21d4J5V6sk7k9pQypblBTYj2/rlVeT445a/d3qXk7Hzwq2wRW6lU08CExtIEmWpOnXZM9vwc+6VqnXajssfXELQW6YXwOxzOoJeuerkFq45lAlbKPa81xi3ey9RXfGd6pEQKg9zstcgIvnG2d0Db5pA7zxQuWdseTVa1hlTbB1DJ+WaatGhKTmwom8hHnSgYGVhRwEp2ZK7bvMGk/R2t0GEr6KYKkRC5VAqWeM+zDa7dmw1Wm2+2V1soTAuyF6B4NnpoWFoHxaAPmtkPQBUHSGnXrt5Dtg6EDs0FLNQ8CLlZOvSZHp/qrsyJTtnXrfQKSu cxdSt0Sg Zr5TmxVY8GeJQXDfa6KHCW6tH8b6hQ4lRYJpWmHjeJ1mqVchlA2af1eyGPb2jicINB9NHrbkoalg0kwfH4SLvqi0gQruKJWitXdutS47Oy8TygRkYLvfSlnDh/07HLkZJYQuhwu3XqK1bRZM= 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 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. That implies that folios must be at least order-4, but you can still look up a folio at index 23 and get back the folio which was stored at index 16 (range 16-31). hugetlbfs made the mistake of 'hstate->order' and it's still not fixed. It's a little better than it was (thanks to Sid), but more work is needed. Just use the same approach as THPs or you're going to end up hurt.