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 D21F7C433F5 for ; Mon, 11 Oct 2021 20:07:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3936660EE7 for ; Mon, 11 Oct 2021 20:07:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3936660EE7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7AD906B0071; Mon, 11 Oct 2021 16:07:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75DE26B0072; Mon, 11 Oct 2021 16:07:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6251B6B0073; Mon, 11 Oct 2021 16:07:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id 4EB206B0071 for ; Mon, 11 Oct 2021 16:07:28 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0364F3017E for ; Mon, 11 Oct 2021 20:07:28 +0000 (UTC) X-FDA: 78685241376.08.016DBD7 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf03.hostedemail.com (Postfix) with ESMTP id 710783001BDD for ; Mon, 11 Oct 2021 20:07:27 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id bl14so4114538qkb.4 for ; Mon, 11 Oct 2021 13:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DkWMS9sNuUsoeWUX5q4LagM8Y02J2w1JYl1co0ISN+Q=; b=H2LoX6jUHdPAoBvUfWVZ5V80fV4G3Werq4c9VaeWS/96wBCj9OTD4GMV4X07uXo4DY bXFP7YKuY6vIP19VqFY7OVQx1/QxiZcpr1/znBpBQlDTmgWrRP3vJJ9i9aRPqaeM1rCB YKIrpJ901zS8gA9t1K9KWQSujDvy9p3m2Icd98Gpcgzfrh/ItDVOq3Jqogc43kLvmWww IlA2PtyYU///32ZHKESaX5lqtRqaQECVacbr6B6wjJ4qGHee1WPFuCSDp7ZexFiHJHUw GJ1SdgaAYSTMjyegPsghR0uKTYmRgYuFUl64rliTkVBdhTz2gTY/BbEFEPLgW5GLH7j0 zEmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DkWMS9sNuUsoeWUX5q4LagM8Y02J2w1JYl1co0ISN+Q=; b=uEVxHhgilDF8aAVCSfysyGKviHx8e11L1S+6OxnSy+Bi3cO9TadsWIvDQgxQcqHA1o jj1QaR706pXjeM/J8jaYTBc/um0dfnd8V5uXFxkYgjK+WtbaTl+4GmiLBkXdDer9Xb0O hgP31fSINLy/rX4W0afG3AZNJWF6ZxzF0akYjU8cl/1mc/2/9YOYaf7wPnH8uqBKynUO EHpZdSOjO+ndjhjmQx/Szml7m1chebDfBBz48Wy5jTbzZw5zoL+6fdg693IGqOGIShMW +AvQ6139nc+sKL4a0xQ7c8b2rDr757hP2GY7QCf+jf25NnQ+CcarwUHfKb/Dn81D5jxg uuuw== X-Gm-Message-State: AOAM531HGBLq/L8/k+uCQBIJwxGaSKCTZReKIzy/ivOLtRli7PeP46u1 8gOp9EA/UB76dtdJ41Ssj517TZSuMWWTSQ== X-Google-Smtp-Source: ABdhPJypxVD0iIs9w6GV/wDvwxJzqN6dNCPhwJ4NLpnmzqaRqufVD/7T5VOM9cD3Uv9ta/UXm+r4lg== X-Received: by 2002:a37:34a:: with SMTP id 71mr8755586qkd.242.1633982846622; Mon, 11 Oct 2021 13:07:26 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id e14sm3852842qtm.13.2021.10.11.13.07.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 13:07:15 -0700 (PDT) Date: Mon, 11 Oct 2021 16:07:14 -0400 From: Johannes Weiner To: "Matthew Wilcox (Oracle)" Cc: linux-mm@kvack.org Subject: Re: [PATCH 00/62] Separate struct slab from struct page Message-ID: References: <20211004134650.4031813-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211004134650.4031813-1-willy@infradead.org> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 710783001BDD X-Stat-Signature: 4w63uakyyi4n61zidrsemtyfm3hfqp6h Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=H2LoX6jU; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.180 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-HE-Tag: 1633982847-51057 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 Mon, Oct 04, 2021 at 02:45:48PM +0100, Matthew Wilcox (Oracle) wrote: > This is an offshoot of the folio work, although it does not depend on any > of the outstanding pieces of folio work. One of the more complex parts > of the struct page definition is the parts used by the slab allocators. > It would be good for the MM in general if struct slab were its own data > type, and it also helps to prevent tail pages from slipping in anywhere. > > The slub conversion is done "properly", ie in individually reviewable, > bisectable chunks. The slab & slob conversions are slapdash. The > patches to switch bootmem & zsmalloc away from slab elements are also > expedient instead of well thought through. The KASAN and memcg parts > would also benefit from a more thoughtful approach. This looks great to me. It's a huge step in disentangling struct page, and it's already showing very cool downstream effects in somewhat unexpected places like the memory cgroup controller. > I'm not entirely happy with slab_test_cache() for a predicate name. > I actually liked SlabAllocation() better, but then I remembered that we're > trying to get away from InterCapping, and somehow slab_test_allocation() > didn't feel right either. I touched on this in the reply to the memcg patch, but I wonder if it would be better to not have this test against struct slab at all. It's basically a type test that means slab_is_slab(), and its existence implies that if you see 'struct slab' somewhere, you don't know for sure - without having more context - whether it's been vetted or not. This makes 'struct slab' and option/maybe type that needs a method of self-identification. Right now it can use the PG_slab bit in the flags field shared with the page, but if it were separately allocated some day, that would occupy dedicated memory. And describing memory, that's struct page's role: to identify what's sitting behind a random pfn or an address. "struct page should be a pointer and a type tag", or something like that ;-) If instead of this: slab = virt_to_slab(p); if (!slab_test_cache(slab)) { page = (struct page *)slab; do_page_things(page); } else { ... } you wrote it like this: page = virt_to_page(p); if (PageSlab(page)) { /* page->type */ slab = page_slab(page); /* page->pointer */ do_slab_things(slab); } else { do_bypass_things(page); } it would keep the ambiguity and type resolution in the domain of the page, and it would make struct slab a strong type that doesn't need to self-identify.