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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CB68C4332F for ; Thu, 14 Oct 2021 13:10:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CA841610CC for ; Thu, 14 Oct 2021 13:10:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CA841610CC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 30BF5900002; Thu, 14 Oct 2021 09:10:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BA2F6B0071; Thu, 14 Oct 2021 09:10:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 181D3900002; Thu, 14 Oct 2021 09:10:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 0BB2D6B006C for ; Thu, 14 Oct 2021 09:10:23 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BE02A1810F5C3 for ; Thu, 14 Oct 2021 13:10:22 +0000 (UTC) X-FDA: 78695076684.25.3FB47D0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 62A761907 for ; Thu, 14 Oct 2021 13:10:20 +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=fvw8mi1OONYQQAat/TNLHTAKhGZLbTYqzArlhydgS+w=; b=EKVfuW2wRySFbtAghEOZSdGXLz nrX3YHenq06+b3sBdMA7rHl2xRoNsH0p9+at7Pr5QF0f5QjWl5zz962KmY6tij6Xy3QTPBn74Yl0V +e9OnIIMlt3gtWP13VxVZXqChFSpDoExAqNjGCN2EdZGSq0+nEqWX/K9PIZPR0PKT+ZTWDp7s63/v H0czeKAqPKT3CukqhXlSRYu8ShjvJE6BmcrWCXSttCCzY11xs05QVETh1ot5RnYicdmE2U2t4dOPt 3NnqUlH85LpAu0lHOz2B+OxJPp3XtpGZb59xE0vD/CXT7oLbjic8EqzWDnD/WxAzt07OuXxg5JGTd BzNlI+EQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mb0Tg-008Llu-HZ; Thu, 14 Oct 2021 13:09:05 +0000 Date: Thu, 14 Oct 2021 14:08:56 +0100 From: Matthew Wilcox To: Johannes Weiner Cc: David Hildenbrand , Kent Overstreet , linux-mm@kvack.org Subject: Re: [PATCH 03/62] mm: Split slab into its own type Message-ID: References: <20211004134650.4031813-4-willy@infradead.org> <02a055cd-19d6-6e1d-59bb-e9e5f9f1da5b@redhat.com> <425cd66f-2040-4278-6149-69a329a82f79@redhat.com> <842357c1-bec2-654e-c782-569b1fd627b2@redhat.com> <4cccc03f-1a9b-a45f-082f-77a4b37f6761@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 62A761907 X-Stat-Signature: 1sn8bqhwfhfg3dm1o6jkmii81ps4jn81 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EKVfuW2w; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1634217020-582279 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 Thu, Oct 14, 2021 at 08:44:39AM -0400, Johannes Weiner wrote: > A clearer overarching design proposal that exists in more than one > head, that people agree on, and that is concrete enough to allow > others to make educated guesses on how random snippets of code would > or should look like in the new world, would help immensely. > > (This applies here, but to a certain degree to folio as well.) Folios really are a simple design proposal: They're a page which is not a tail page. I didn't want to do any of this work on slabs and, and, and, and. I want to get back to working on large pages in the page cache. Yes, the same principles can also be used to split new types (such as slab) out of struct page, but I don't want to be working on any of that! I don't even want to be working on separately allocated memory descriptors. I agree it's a lot less churn to split slab out of page first, then convert the remaining page users to folios than it is to convert sl[aou]b to folios, then later split it apart into its own type.