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 B9B80C282DE for ; Thu, 13 Mar 2025 14:48:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB2F9280003; Thu, 13 Mar 2025 10:48:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6457280002; Thu, 13 Mar 2025 10:48:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C29A8280003; Thu, 13 Mar 2025 10:48:52 -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 A290E280002 for ; Thu, 13 Mar 2025 10:48:52 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3702B120157 for ; Thu, 13 Mar 2025 14:48:53 +0000 (UTC) X-FDA: 83216809746.15.78F7DA5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 7B0D4C0016 for ; Thu, 13 Mar 2025 14:48:49 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HxHbY97B; 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741877331; 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: references:dkim-signature; bh=mguzRb+gPXLs25/hVD578nVINZFeIyunVRngCh085s0=; b=G+s8siu+C2tCDNtq9ptkTZ5tQu/Rfslous0/PP6mT1oFIXHdz6ZW8E8Yg6Hv2dSYaSqYIL t2nO+FwoK8IJfJV1voNC+YPnFc44PwOOKHyNauc0RQN/vp0v/XtTKEEsKtmOLBWLYA8yDm er8TiqtXTJ4iPfU7LNI3pnfHSFlgcTQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HxHbY97B; 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741877331; a=rsa-sha256; cv=none; b=Um2kZ9kGDdefEcQeCKk/KsDLBNZFbPpz0DdzCpTT8oZbeGyaPDzG03cRiHGfcvnK5L4xWz 4LknbIB+CNSPx4qyuhX6vuBV2tZh3a2FS0moPqlOi+Mczne5k3AuuSeIjeh5k7lwbje0rn 1WV+Btegkp0cb43y+YbBJKvlvcEObmU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=mguzRb+gPXLs25/hVD578nVINZFeIyunVRngCh085s0=; b=HxHbY97BpitcysnKxzER87gNkT Ge8+ZIGw41FvbtfU2UCw9Xt3Bh95l/PF72xDc4Ly3+Gv4Ld2YFHvwppKwOQuHRP0aAsolCLNmE/Ty YWNGxd8vFM8KZ2UH14X1Jyq3+FOZaexRhx8cXSOMtwRqqXKQ7DVt6gfjBLkVrObygnBD/TiUqOq/u 6P5PiNzCXMTwcU8PB1J3g2POm3kKMwyWvBmi1Kh2lsnFxWbpklsQ/h9+QhRq2z+PAXFOq0fqn+5po axH8JlTtlFO5vaemTnkdk63UAgfjhZvIynyWzq3t05ZdA109hxq2VE3g7o4Qrv/T3ty+oywDObT2b QELUirYQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tsjrZ-0000000HDFq-07qt; Thu, 13 Mar 2025 14:48:45 +0000 Date: Thu, 13 Mar 2025 14:48:44 +0000 From: Matthew Wilcox To: linux-mm@kvack.org Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Zi Yan , David Hildenbrand Subject: memcg_data and the page/folio/slab split Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 7B0D4C0016 X-Rspamd-Server: rspam03 X-Stat-Signature: bh9f7c86ayfqewre4wypozqf1uexbiew X-HE-Tag: 1741877329-553880 X-HE-Meta: U2FsdGVkX1/DJjHZ+wz/T9/BPPIFSAkB6EXwqV8muoWi0iwRQAKM4Xs20UwGfdJ8dSYaC52BC97wnLmlrz1ZrfmUKnpF5+QeT5UPX1GE9AZq7ioGdCk5pqYzF47If4sRsKvVzHv9tM3VtjnRLF72elnBH0jHywjgnn74unDyd+nxLaSlyfJkDggfkF6FNjLMU8uMMT7YkqmgYXz6esvBOWalLzTTTFLz39deqbCRxHRKnh3uFBT+mHIm21GTi5a9wBRZlCkhW3mu9Sfg8ieQH2xim8k9Ixh7cuZcdJG1eiumsa7XalmywOMMHkbKvxDCfX+gyG53FeyQ2ObW3yqXd4dlXO98uMeI/2Tdir+8TbGzOpAL3L8D4s4zqSMQjvQr2IKHS9cCjhnT1cTVCHPyO9zhzEefKlKBmG2Vrs9C7hkZndfwcNM9WpA/lkQN75M9dyIgmPGH9M3a21UIrm8NI2iGtahSACwJ0UPSeKmdQVNSqarVzfvt7qp2r4SjUrd3HtwBUnPU7C0EVQQxoe1k+cs4LFEbKjYsLRX6GDKG2XeODVb5bBman0+KPB4FOMtw3muObDnHMDNyoEuIHw4MTTFXiUuZnJabxK0YtwS7acFO1S15aSPco1CNREDDvua2ArI3TAaIuxhE1Vq77sdLqz3st4JAiQR1WxZxTDaxwIeppZsOBW5dVSY8iaJYPagkWrqWrt1UUi0+adToPYwGHQPvlpBfbImskH38ZCziRCgnF7xAK8U4lG0J+R0gP0j3dV590QMF6o33e7p7xMEHsin69fFG2JuIxzofpOAL9nsir4kVobEw/zPzabS9qfFbDRyfgazxJlLKSFv1Wr3EI3ns+bs1Bx9+i2p/ZYWKknz5NiH/HplAfaJz4QoY7LDqav7p0RNoRZzdftR5vuSdeQyLJRM0fgWFPxhuclgmjyNNIqAQ6ORVTDpx2WCDFjg1w8zRaX81JfveqCXp4V1 ayTSQnPE IFtmbk2KokdDE0m6bZAr4Jet2Kh1zPS775qXGwMdDLt4nTGocQJoFYN2fZ6wvXdD/SWYkutY7rTbL0LHbmr93ntnIuHXjIB3VtJJeAl7utzHm0PEP5hdWARmNAcxnx7Hwh17oMFOMcywf91wcALFNTbEv2lS8+GK1MTtX9CVAoNtKj9fWTFnYtsBtXxtF+gfzVUY9HZ0rgVcn3TskuIMqHdRYOqCUaW0V9awPLR4GSmj65ge8LuFoaDqy+KUvbyfyexW4fpD7UvwGXjbWzJcaCg9YubdiYr42NZ/RcN/V592NvM5xcPwLTRtSrU8hko0xH5shQzoyLMb+HUs= 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: I started working on 'struct acctmem' as hinted at in https://kernelnewbies.org/MatthewWilcox/Memdescs However, as I did so, I became aware of two things. First, we don't need acctmem until (unless?) we remove page->flags, which is not on the cards for 2025. Second, we actually have distinct things stored in memcg_data and those things line up perfectly with page/slab/folio. That is, alloc_page(GFP_ACCOUNT) always stores an obj_cgroup pointer there (with the KMEM flag set). Slab always stores an slabobj_ext pointer (with the OBJEXTS flag set) and folios always store a mem_cgroup pointer there. Maybe that's obvious to those who work on memcg, but I didn't know that; I just saw code that could handle all three kinds of accounting. So, new plan. For 2025, we have struct slab directly pointing to slabobj_ext (with no flag, because we know anything that is a slab has this pointer). struct folio directly points to mem_cgroup. And alloc_page(GFP_ACCOUNT) uses page->memdesc with a type in the bottom four bits to say that this is a pointer to an obj_cgroup. Obviously we don't have a page->memdesc yet, so we'll keep storing pointers in page->memcg_data until we're ready to switch over. But I do have a few patches to separate out GFP_ACCOUNT allocations from folio allocations that I think are worth merging now, and I'll send those imminently (think of this as a [-1/n] email). We can't get rid of all the "handle any kind of accounting" code today because we lose information about whether this memory is a file/anon folio vs a GFP_ACCOUNT allocation in the freeing path. That's a today problem that will get solved, but not in this patchset.