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 A4011C02194 for ; Fri, 7 Feb 2025 15:02:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47A90280005; Fri, 7 Feb 2025 10:02:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 42A32280001; Fri, 7 Feb 2025 10:02:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F1C7280005; Fri, 7 Feb 2025 10:02:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0F790280001 for ; Fri, 7 Feb 2025 10:02:10 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 596F1161CF8 for ; Fri, 7 Feb 2025 15:00:20 +0000 (UTC) X-FDA: 83093459442.29.26A618E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 70FF840014 for ; Fri, 7 Feb 2025 15:00:18 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cumFyIH7; dmarc=none; spf=none (imf12.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=1738940418; a=rsa-sha256; cv=none; b=OYz1sISRBsSi3IMgcWEGBTR2rAApCUaXqkhPZ5iMyhqAKTRLKzgL/JEx798ycx6Xb+n/ha 3R4tRxlM1e9qwRFFIaYOH8yofl8E8DxMyVG9JTWP2NtVpMu/fQ3wEnH6F3lO/olKnVv5gu OvErUp34oINDs1bkTZYpOQqhPmw6wWM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cumFyIH7; dmarc=none; spf=none (imf12.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=1738940418; 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=7zWbeTI0iVXnsJeV3Y+pOkoTDbxGkFIzjOKkyY+w2L8=; b=IgXHcDTtZPEWSonkqYPOwyXT9hgLkM7oQblV1JNIfXUBmUujQPfURXCzvnTyWBbbpUq3en ZEGp8CUuCRwtOPe9AYqGHoLWC1XgOnasmEZFzleYF68vzGvX3e6nIJY3XhfUX3SuTPRlN4 25zhRULEIWO5NsJuFf8+zNgEVCnVEBQ= 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=7zWbeTI0iVXnsJeV3Y+pOkoTDbxGkFIzjOKkyY+w2L8=; b=cumFyIH70i0rvsVq0RcTinTMou MJnOFWpJEgd9qIDi1XRi4wAqhVp2ljm2hfbS4fORfJHcGFAuGL8/ahyM/Y5gvebNLVkd0uGhEfdWe PWrg7IF44uMSMh7HGbCXNk+xYy0lVkNK6MYLHjC0Vza3XtdYRZCxCYwLzmMsrKzTs+APMW8ANUTHh XiUCKn6NPWrvsiljf52kB9aeyMRgT6f3WE9E9O3jd27QNjpNGKrT0idMAXeI5QtaXFg2WKA549/vh /RVvdWsgvJkRntgOn1bwea11C55MQFJK+c9uvNqeRhYN2b3AIleGekgr5P9N2a9xlN1BeB0J50xJg 573udtsA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tgPpz-000000083qW-47WG; Fri, 07 Feb 2025 15:00:12 +0000 Date: Fri, 7 Feb 2025 15:00:11 +0000 From: Matthew Wilcox To: Zi Yan Cc: Andrew Morton , linux-mm@kvack.org, "Kirill A . Shutemov" , Ryan Roberts , Hugh Dickins , David Hildenbrand , Yang Shi , Miaohe Lin , Kefeng Wang , Yu Zhao , John Hubbard , Baolin Wang , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 0/7] Buddy allocator like (or non-uniform) folio split Message-ID: References: <20250205031417.1771278-1-ziy@nvidia.com> <20250206000111.6c54e67d1933f8bbc01a46cd@linux-foundation.org> <019EB6CA-0F4B-496A-B2AE-A3A553585281@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 70FF840014 X-Rspamd-Server: rspam12 X-Stat-Signature: u9zdzsmjcq1wieedqn47ep91cf3nxc6k X-HE-Tag: 1738940418-951569 X-HE-Meta: U2FsdGVkX19ngXzh4YV4w6fySahOnK5ADyP2Cef1phTEbfNTEBmn+KisQaqAb58rj/7NYSG9l++UvV7uBhvoYFC5HrhJ4qjmFj2NxUYn3sF9RaCpDk+n+Xu2PCCGwjA0DmId/DCcIU/ea0qLIbXFCgWSQ6TM50jEpQ/hKkLXy4jMJFHW7uxi+Tb8kf58cdVLsE32rYWJNMHN7sDlIKYoKsTrl7cL6BLPiwWLwuZciw9z78u8JBwjTHcxhGQWEfhR7wE5jQ8o/RKaMxh4FAx03s+B/ka0zsCulnh2AAk2H4trGENMbQIk9W9lS3ftHQ/dSQlB2Rzs0KUzbSKh9mR1tRcEGzfG6adbR+CZ6gl94ACc0giI+yeKs9engbRvz7fTI53wVkD2WYanECrMYOnb7/E03AvXohu5HgZYlTmWqoSK1ZOb5dsz+ZinI5GFxPMBgE+U74SmdiVwEncMfXqAJ65JrYnGEmrW9fzfDoP+yd01lXU44Aru9MT1PqBbpClp3UTFcP924K53RnkehFfc+FAeWV3nzCrTvccg5LVBLv7rzHU505ZYPX++2UsP7RQCIIOrcezb8y6zsSSCossACkLjAzUKkGbCaLqgrKWYV18jRd48AVP1SFBw+25MOHZ1HoCpPty4W0FR4cQLBx8oOfZ5YcteAG7zxn1yym6M8lEHbsgft67HZcQwWjcbq89mMXvcJ0UpmqZ419hfsQsqS0nWbUURmoDWl2Mwcv5jvDSdLDUaLHfYuMbQ8epyRvueUTiODT16F5sk+pc/h7jNC2Cb2HVl/zl6uLLQCQzLZsQ1QcgW8FLInbeqtlUNhbn6joqtXfeK3tnkEDNjMq6ibkWDEfHhOJ/NLq91D4vgT1/+rZBcIeINjGZBzhig63d5T8wTiAIkIZTMyrV/IlKHZCZ9tCkGVmAdhclbJTJiCBtPGNmNITuwEVY06Yn8wUWxVIZlEJIA5Qvb8v64xz+ N2jE/X+0 2u+wcHVFEbUXFuvJON3M7NT1Stk+2mzGAOzfoVa+AamxvkF7RJ1pGp6MHeQyICyrUdP/7wmUdYivPseUcgmMRG9rPQjVFIL9K6X6y+w+0/YIxa/JuGyXpMKs5r7cwZFgWlFOt7dDGIJ0GIUn47NBXkxU9sr8TS1ruXTzTIJ659gFZYceQa6ttVNTlFfZIMXzs0Z9X+PRrPHWLsynER1QBDZVzDTCQy1MmEEKZhRbqRIN1Ac0= 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 Fri, Feb 07, 2025 at 09:35:27AM -0500, Zi Yan wrote: > On 7 Feb 2025, at 9:25, Matthew Wilcox wrote: > > As part of your series, I'd like to remove that limitation, so we'd need > > to allocate log_64(n - m) [ok, more complex than that, but ykwim]. So > > it's not quite "only allocate one node", but it's allocate O(log(current > > number of nodes needed to be allocated)). > > > > Makes sense? > > Yes. > > To remove that order-12 limitation, do shmem_split_large_entry() and > __filemap_add_folio() need some change as well? Both call xas_split_alloc(). > But I do not know if they will see splitting order-12 to order-(0 to 5). __filemap_add_folio() doesn't need to fracture like it currently does; it can do the same minimum split. The situation is that we've got a shadow entry which covers 2^n slots, and now we want to add a folio which only covers 2^m slots with m < n. Leaving n-m shadow entries in the tree with orders ranging from m to n-1 makes more sense than the eager split. shmem is the same, except that it's storing swap entries instead of shadow entries.