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 BD8EFC25B74 for ; Tue, 21 May 2024 14:44:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E6E06B008C; Tue, 21 May 2024 10:44:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 296C36B0093; Tue, 21 May 2024 10:44:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15DAB6B0095; Tue, 21 May 2024 10:44:29 -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 ECBAD6B008C for ; Tue, 21 May 2024 10:44:28 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4FB10410A8 for ; Tue, 21 May 2024 14:44:28 +0000 (UTC) X-FDA: 82142673816.09.DF1BBC3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id 80EA540003 for ; Tue, 21 May 2024 14:44:26 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IMIxj3Qq; dmarc=none; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716302666; 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=MtcuEyVIsdI4Kek6XZWyT/nyjJfHP32Eu+F1cNxK/iw=; b=3hghgaBB+S5qCp9jvjrd0IUnKB/Dhp8OgVbsCUdiP8D3br5e2iENmBR6DIHe6ea8W27Wo4 djhDpgOxL3XbSMfFaqTRUu7Y+r1WNCryrto6nIlw0yBNPfY45nhXu6c+vqeoQ2gnt2s5ba QqKph0+0Yt4cTS/5cOaZ2jjpiv6eWks= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716302666; a=rsa-sha256; cv=none; b=DOPF8F5M1qpD94ejWhYqmS1LauY5VmMisrtM79wBy6bXub48fq5udxEM6G8XKYMlapikFf mzYMizsXKThHs8n9pVJjLVXAnSF9H5crznHGs6eDclLRRXvk8EGYAaH7nmuKUcAoBWtvWA wd3AIfdpn45b0yPaEXhYmHKZvLV4DiU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IMIxj3Qq; dmarc=none; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org 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=MtcuEyVIsdI4Kek6XZWyT/nyjJfHP32Eu+F1cNxK/iw=; b=IMIxj3QqncsMxlzUU/eup433kW yoJ3ZRWKVzvuZ7ebyuYTU57ySbGdKo3QFND+o1JwPZntV7xHMFNkFJhEx8TnH1UVMchsBkNLhpfDU pOsBz7nGLJLJO2rgES9JNDA9cpYCVoTNDIZv4QEn2E9vYSG54o37m1bHbX98FtfvmmEIyW1iW2NQR UZBO8/mIQo13B4bAIcVH/nygoXP1VOg7ZPWB3BeBwuIOVsMPrqE/gdwoFcgwXv4Y5zobvYzB27HOs 4lIpz8Je6AjCji66oDnNKr2BqVz5VRZ+Rpga3gwHp8vBySco/49ksazaAHx3N9f8Ivncja/1cEgmc sqIDFzww==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9Qiz-0000000HHMP-2gOT; Tue, 21 May 2024 14:44:21 +0000 Date: Tue, 21 May 2024 15:44:21 +0100 From: Matthew Wilcox To: Kefeng Wang Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes Subject: Re: [PATCH] mm: memcontrol: remove page_memcg() Message-ID: References: <20240521131556.142176-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240521131556.142176-1-wangkefeng.wang@huawei.com> X-Stat-Signature: 4et143mm8rs6nrxi96nog4hhtjkmm3sp X-Rspamd-Queue-Id: 80EA540003 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1716302666-944353 X-HE-Meta: U2FsdGVkX1+WM+gRwyK/oRUWoWGVLoyxWa6q+BxFJqlmulfk1WoOaOek7eS6jDSI6mc0VjFprElMj/aXKUA8gfzoW9qvmrQZZ+6Xa6BSGmM8N2J4/Aw1aft4ewuEz+iygazRDkucQbyeQtG5R17aSAo1bwzOHOZRj/4OjTFnFyKm8RiYAczuhOrzhZ01oSyErlUtsBSzlzKFcQTQWyZfMDO9fVQVfL0bXU7IeFsjTzMYtIN2ZzcvEoLMxzUhTo5H8KISDRxIfzopxrVSiEi2BAEWDWz7QnLIAiuUrAQgrql1kpIEJKyUknmVE5vOV90WJF8+JzYzeqqFPE+ZaOsWHPhWV2EW0DDPOTpPzWzOauhDz8WlPZRwamZswHNwuGpUOXvC7xw1ZLc/TQ5RyH9b2KL8Nop870jxwPqcaedOGnsXSMQ5bonqzf+E9Lyxi9f8eIJNO6QOFR481OmCNqukzALzWPcivliNHGVJtCSboEiePhKhrNI8jeGGImXeiXOG8ddFG8YB71TcvpDJ21OUkoHHOQJCyetNMMQAgqRc0VCmPMlgNZciENjlQHO9DgIgAlC5+BfuvgkmLievh4pWATP5fkF6Bcq5G0FeeqlKJTQHTpBUm1aQD3rPPxqj2sslTBXjuD1kpTNLkIdz4Evs+HYYKVCy8Y6tFC9b/evwbJwrEWh7aMh85uAg6TDi8v8dDD3kmUsZ+DCxn1lWYEN+ZJklUSe+3GPFmP6FQ9e9lUbD0EYz90WIpcRs+8TkoLdnPSLcpzXWl1KYOS4/+PIxQSI+GPyw1TcnmfbUpkYleXo2RghX8PFdzDcHuQdtG7IeDHX5e32UGEmZY2Cm0L1qVyVHDnvqJSGUIsoQwyPeiuxzxddW35YeX5lUvdBWb7mvlfv4UGH+gkDblPBb6vhZ1QQhw8gyexrO0SSatvvgaeZvw7wuBTfqiEGwIWjysY0oU9HR0AGkeEB1ja1/NLA ZwsWjaxQ mMZq7EAj392/rFWGRH+sagv32vRRmT9TLbp58s3ETBscjXmTLkUWnLr8Xlpbvs96s+V7asrOOt9fvtHCqoM9Dq+cu4bD7a9G2dTAVDKu4oE+RJ9uvpHXn6z17JmR3kpEqjTIeEWr3Xmgj15IYIuKTVt7evOKBlzPv0HIpVX5+r45yBpW6t+GkVe0Mkg== 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 Tue, May 21, 2024 at 09:15:56PM +0800, Kefeng Wang wrote: > The page_memcg() only called by mod_memcg_page_state(), so squash it to > cleanup page_memcg(). This isn't wrong, except that the entire usage of memcg is wrong in the only two callers of mod_memcg_page_state(): $ git grep mod_memcg_page_state include/linux/memcontrol.h:static inline void mod_memcg_page_state(struct page *page, include/linux/memcontrol.h:static inline void mod_memcg_page_state(struct page *page, mm/vmalloc.c: mod_memcg_page_state(page, MEMCG_VMALLOC, -1); mm/vmalloc.c: mod_memcg_page_state(area->pages[i], MEMCG_VMALLOC, 1); The memcg should not be attached to the individual pages that make up a vmalloc allocation. Rather, it should be managed by the vmalloc allocation itself. I don't have the knowledge to poke around inside vmalloc right now, but maybe somebody else could take that on.