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 3E9F3C433F5 for ; Sun, 29 May 2022 03:31:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C0948D0003; Sat, 28 May 2022 23:31:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54B578D0002; Sat, 28 May 2022 23:31:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 410D68D0003; Sat, 28 May 2022 23:31:30 -0400 (EDT) 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 2D9598D0002 for ; Sat, 28 May 2022 23:31:30 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id DAB59802D4 for ; Sun, 29 May 2022 03:31:29 +0000 (UTC) X-FDA: 79517355498.16.A99A13C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 43FEE1A0046 for ; Sun, 29 May 2022 03:31:13 +0000 (UTC) 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=qyOue3vhI9r64/cB5hJYFTVsL61v9tYIZ/ebY1l6Usk=; b=Ptypr/RmNCnkuOvkKpm4oFUly8 7rRrFWo0GsMzRV5Z+J7L1JCyAeqB5ATCDQg1+WvGM/JZx7m5IYRwiMNYlQqcoBr5CTJWnlsAI3zPN dZ++yUw2Aj3yYCYk5yd7FRuQPYNIkUtxFucRzg1wxbL+GSgxwyDGwDJz+LeBUObZRPwavmW8dXbOM oxey5EfzRfR5Md56svvfw12ouZh44fI2tuWwJiem8uF1CUuei3zea43okhgGukFuSrki5m7/IO5gD YxNATO2aCmtvHrwAsroAzUP6PxBtYPtQzkVGL1mSbkWkGVBU7sV0KTrlc1DRwnitVfukgT+l31Edv EDfCDE2w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nv9dz-003M3H-Mw; Sun, 29 May 2022 03:31:07 +0000 Date: Sun, 29 May 2022 04:31:07 +0100 From: Matthew Wilcox To: Muchun Song Cc: bh1scw@gmail.com, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/slub: replace alloc_pages with folio_alloc Message-ID: References: <20220528161157.3934825-1-bh1scw@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="Ptypr/Rm"; dmarc=none; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 43FEE1A0046 X-Stat-Signature: tymfe9oipjb7u1zypg95cagfygdj4sro X-HE-Tag: 1653795073-688349 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: On Sun, May 29, 2022 at 10:58:18AM +0800, Muchun Song wrote: > On Sat, May 28, 2022 at 05:27:11PM +0100, Matthew Wilcox wrote: > > On Sun, May 29, 2022 at 12:11:58AM +0800, bh1scw@gmail.com wrote: > > > From: Fanjun Kong > > > > > > This patch will use folio allocation functions for allocating pages. > > > > That's not actually a good idea. folio_alloc() will do the > > prep_transhuge_page() step which isn't needed for slab. > > You mean folio_alloc() is dedicated for THP allocation? It is a little > surprise to me. I thought folio_alloc() is just a variant of alloc_page(), > which returns a folio struct instead of a page. Seems like I was wrong. > May I ask what made us decide to do this? Yeah, the naming isn't great here. The problem didn't really occur to me until I saw this patch, and I don't have a good solution yet. We're in the middle of a transition, but the transition is likely to take years and I don't think we necessarily have the final form of the transition fully agreed to or understood, so we should come up with something better for the transition. Ignoring the naming here, memory allocated to filesystems can be split, but the split can fail, so they need the page-deferred-list and the DTOR. Memory allocated to slab cannot be split, so initialising the page-deferred-list is a waste of time. The end-goal is to split apart allocating the memory from allocating its memory descriptor (which I like to call memdesc). So for filesystem folios, we'd call slab to allocate a struct folio and then tell the buddy allocator "here is the memdesc of type folio, allocate me 2^n pages and make pfn_to_memdesc return this memdesc for each of the 2^n pages in it". In this end-goal, slab would also allocate a struct slab (... there's a recursion problem here which has a solution ...), and then allocate 2^n pages. But until we're ready to shrink struct page down to one or two words, doing this is just a waste of memory and time. So I still don't have a good solution to receiving patches like this other than maybe adding a comment like /* Do not change this to allocate a folio */ which will be ignored.