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 D0BC6C282DE for ; Thu, 13 Mar 2025 17:06:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA52328000D; Thu, 13 Mar 2025 13:06:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C559C280001; Thu, 13 Mar 2025 13:06:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B446D28000D; Thu, 13 Mar 2025 13:06:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9558A280001 for ; Thu, 13 Mar 2025 13:06:51 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C93CCC0360 for ; Thu, 13 Mar 2025 17:06:51 +0000 (UTC) X-FDA: 83217157422.01.F6FA9BE Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) by imf05.hostedemail.com (Postfix) with ESMTP id 55CD9100004 for ; Thu, 13 Mar 2025 17:06:46 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=aretlnSe; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741885610; a=rsa-sha256; cv=none; b=FlPWv8cG8YvZwzIwyioO8U3XUisZfeK0owAkR/RcRQhz/n6b5SYpbilef/F9T/bpXsOb+v nbCt88uppdp7ZxR8aY8/Dq/OXye3zHlFn5iOGH5snwu/AJUx6feBFHp36G+gauDmCZ/izW 5y5GyL8AEv6owhduSU5ixjMbf1NKRNE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=aretlnSe; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741885610; 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=sL93smIZeVR4GcQO3ToP/X6NR2rYL3wohPUPicLbXT0=; b=QcIqHvcw2YpNUEEto5J8zeOfAXXMjoLHRs5fFD7vY4JHyepJLEiK+AEcgNivyraY6rUOVi AeW9d6qWBIhTzbeI2mYXC8n1Q6FZgO6qO/SxDJ27fN1xRrAikOl1krYNzmIdik7/InhS5H sE/QmUnvfMRh5sQQTyf0/9k7GiR4/Y8= Date: Thu, 13 Mar 2025 10:06:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741885604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sL93smIZeVR4GcQO3ToP/X6NR2rYL3wohPUPicLbXT0=; b=aretlnSeUy9IX1O8o5UMGcSHO7WVvpr83leM6FTzSpxYMV500r0CIxwbH891wdkvPoNpWb uJ5JcpSq2F30I8cTwatBTO5xt1rsJOHMxNdKPSejpTdM8fisifJRBXyPn8EZcORQ4mx3ob iPMbjxy3TvV05JOYgIcWdIGnHJ8k1uA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Matthew Wilcox Cc: linux-mm@kvack.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Zi Yan , David Hildenbrand Subject: Re: memcg_data and the page/folio/slab split Message-ID: <5e6rtjxoo56cgqhbhs7hvfjfz5cpv7qebsjr7gulxdfvhknhub@z6wvj2gxggbt> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 55CD9100004 X-Stat-Signature: rkyf33scchifrd96igrdswbhpryq3yds X-Rspamd-Server: rspam06 X-HE-Tag: 1741885606-231754 X-HE-Meta: U2FsdGVkX194dfyerEZksBprPD/BQP6KPUoL7kUZ73BnUH+5+lTCC0TiAe4kmY8CA37vqEJMFpwrBYDZe8JFKwR07EcsjPsOqQwGjSGNzcEKUsIO3wozJZmjQVFr5mluiF7M+PrIkHg/4PgVAGNOXADhA4nHS3shkw8T0E0toQeCUbrDyUdx1Ip9KrbFcvvbngC1ku4jHSrgfbet2cpmpNQi/e+mtFB0qZUbc2MsHKcNyvWGbeUcG9SxSHaUPCJcDOmvpoZJ4Dwy3w1xcR0bEKsvK6HOqfTlDp0NZJTJ4CQ3PTJ6QjRciNr9DNjIIsP16DUQHhZPqPNnStOsAa/Q4xsW4ez7jAB5KY1DemXkdF1fKAJ4NyxnSMxe1NWOOPIxiKfCEWor8fxO8cY5nEDCMOx/qE8NyqrpLhfgo2tSHedarroUlNjk2KZpIOvDfaGqRPDFcanEFKjLI5QK+U20urVyagTAjwQWjWHRTuw51AexJX3YKDTly3EXSF9RQFTaUd1GtSXsxejMfnGiSNeiHZeci+RPtvYTFc2srHw4+yvZAj90gdWJv21a6TtDPlGqfDxSFKjXdZpBzgU01kQ+D8dpKnF7JFTOR3iZjnLJjIqT8wxKdzrbFRxMcL+aH9i8orRkkNxdvamKKEdHzLpp9rwU/bHJJ9/UjxlSJANEpmSO87lnFu4xiBenGZcKNa0iqP+4c5KHlgBfbZ1VeuufbsP7Ne0Yr9/fSg66Zo6ocgVvcCm+Dj502k0vi13uzPcUsTCr3aF72EvLnLS37QNNKCXRrJ843YOcRg4wcZKGoaiJqGbcKQ87AxT6/woMKnlgRRWI6YsVH9yRM1qTgUkw3Ht20Ns030fUlrK+WVoIKr3crjjcs8x4Uv24m5lAsnMbkQn8ACI5JMCQEcLifi+a/e68CM4QAOc5hGd0pw1uQCU5DcdvO5BTSy3d0N2KdugE3tC7cgKgNqSdvtW5gC7 /ZH0QHro ylmZPDwQy/qYLsOHLJIJgLYFzdKVCputz3GngrfugZmM6sIqrZBPChB5UB9i+/ZBrXbyCkAPJNQQbIM+5n3Uuurlp/FPNl4gETDjfi5yaYGODVfrBDQS5hQy2R1j0CjMHF98ehLOGidyvuQkhPOxFrA4FbYWjB05mBewk9dRAxtvEFJbBRq78tjTgqjvTFlVOvo38hkuL3W22lsMdMCyDOs4iLSZqqTkiGMtSOO9NNXIsrn6bwd3C7lLQiPdw3jBQmCo3OoJo3U/iuMiw31jJfveOynMxoBOsyA8z 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 Thu, Mar 13, 2025 at 02:48:44PM +0000, Matthew Wilcox wrote: > 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. To be fair I often get confused on page vs folio distinction which your new following plan and the series will make much more clear. > > 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. > > Thanks a lot of this awesome work.