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 3599DC3601A for ; Thu, 3 Apr 2025 18:24:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D19F280009; Thu, 3 Apr 2025 14:24:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 45802280005; Thu, 3 Apr 2025 14:24:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31F19280009; Thu, 3 Apr 2025 14:24:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 12599280005 for ; Thu, 3 Apr 2025 14:24:01 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F210258C65 for ; Thu, 3 Apr 2025 18:24:01 +0000 (UTC) X-FDA: 83293556682.14.260B1DD Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) by imf14.hostedemail.com (Postfix) with ESMTP id 25AEB100008 for ; Thu, 3 Apr 2025 18:23:59 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Vmw5H+da; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.173 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=1743704640; 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=vJhZ3CYu+p3ITqOxO4GkI86MxLYVyuTVhe7EULRD/lU=; b=QJVUOePAiwT+SNrUFhv+TiEsUP6qkYwe+spZfSc6TRj48d2U/p9B+uPd83M4/QrEyMCpPX bEbrTRloaewC8P6qUd39xIz8yj6kEZfUpQzdrFC4xWX5x0qJSJTzu/+HYv0oA6WrWZM54P /XgvdEERgPKxyDXRFH2tXMKqRMRw5Os= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743704640; a=rsa-sha256; cv=none; b=4AqBHXodR3zJtr9TnC5W1NOq9Wq9yXJaLfdTD2Et5RT59ifKcfbu0Rmi9aOcFYnftmA7CW X7FyKcJXHoAa30ifQigCxxsRKSLPdnepQlNVKXCgyti3wHqM1DeONUZ5yFdLIcBj1keQpQ 988b6LYFr2kiHobgXvXQ1U81u+DxfuM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Vmw5H+da; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.173 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev Date: Thu, 3 Apr 2025 11:23:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1743704638; 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=vJhZ3CYu+p3ITqOxO4GkI86MxLYVyuTVhe7EULRD/lU=; b=Vmw5H+daUqRu13FczLvS4tjCsC5LCyWwbJOW2bOMko2YOpzSYVV0jY7PE3UztJWzzuESA8 f565BFwdL2sWgBJ4erQAafS4UGUwWGihKxaLId+fPUdtcVo/KXigeJLzECykUIpJaYPBbc ToZAPxE6/UUMMsH6zNSrzei4lr5371k= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Johannes Weiner Cc: Andrew Morton , Uladzislau Rezki , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [PATCH] memcg: vmalloc: simplify MEMCG_VMALLOC updates Message-ID: References: <20250403053326.26860-1-shakeel.butt@linux.dev> <20250403164741.GB368504@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250403164741.GB368504@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 25AEB100008 X-Stat-Signature: o7iuo1ra5f5r9ojg1mfjzfbd8mss8qog X-Rspam-User: X-HE-Tag: 1743704639-308006 X-HE-Meta: U2FsdGVkX199Nja/AlLolM+NRNkxeVBSdXLKvNMDhM+tYsnEqZHc93ZcQdzqHx1iBxKO4nbnXMOOUzesa+vhMTp38gqLCichmnkbnTT8Ts1Qw0GkRtyCfvl5y8OLUMGkeeQzvC/ifq/eIGC8Iz7gIE1etBewWREId1scSXFUH1SdMplXqMu+0+JBxRAlFyyGAZUJ/JZWuE4gJkCFn8qaglElNKoFuWCK/bZMP2379f5KXLjxaC5Jkwu+o9AZTRuywvkCVvEZD+nf9k6m5yFGWoIzPAfW6qwqKUgnvbhmaTz6UDkovafPds4cGhHYTcZRTA8su2WunKl6pACEvmY9MhR9Cp8ANNyaiDWGHIopOBlJMK8s1cDQ3pMnIyz3WCZGWT68HP5yFs50uIJz0C/xGC/roXv1J5Z0uvI76mu7kWQNV6OpbzLWmRENESfj/v4FTNKw8+91nyVftRgMd92oASneWj5OIeUGo9IUjzKOuLnAnD7Xe7SwjzsGyYdCXt0XBPQE5YjjCn4ZWTOqSvEsQpZPl/tepBWfOQtVj0rdCwiXZRk94sS3RpGFjHjHrkqmK/RquVrs3UgONaq9MOB0uoKs27teKlqUnxSUt0a2Am4WrLJ81WP+HcRvk8GHJ+6kOtRE6iqoAU/xoqPSfh6DMpNDSxZwTPs+qeXR02zJ/SbYivQno1AzEzUH3oOMXPbFZcNZNHzCxx+xP4RGShWQEI1UU8gCHv47UHkVwmE0DgEWwfdsj2TuI/QGUJTAqEKtPpfpti29fbTH9DvUA7T/FZ6m9k5+NltqZxwDlsiRAN7SnGgsxuld4bUg8wVFoDZzaTCubX6gIBTdOfk7KQOP6x18Tk9cdsptlTaKpzcitlsvUOhbEnrTdIPSTtBglY6w4YQ25NgqWdMpOgqfHJszTwtziPuj4g9wn4ESbPolfyM8pqwj+PBCXKf65DX/5TXQlcSYobPO/V1tlx8/3Xi 3Oc4VkB7 rLLzh7Je+3Rq1mm5/6U1A5lDevNL6bO1m3g3MEyeAdRI1RKQ1uE17tKQt1pDyuWRFnv4H4By5Ttph1EMm7Fo6Eq4T6vR3a4nnr3c4Yabezw04C3cNG0H5X8gPKo/2sNDtMAcb7jIcxe63AAxks83tg422n6EZ2NDR7CGvd8RME+sHnXSSoNujxk4k+wa6++iAGupmzlvLncl1rsx+kXwIRDVZrLitZhbnKNk7 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, Apr 03, 2025 at 12:47:41PM -0400, Johannes Weiner wrote: > On Wed, Apr 02, 2025 at 10:33:26PM -0700, Shakeel Butt wrote: > > The vmalloc region can either be charged to a single memcg or none. At > > the moment kernel traverses all the pages backing the vmalloc region to > > update the MEMCG_VMALLOC stat. However there is no need to look at all > > the pages as all those pages will be charged to a single memcg or none. > > Simplify the MEMCG_VMALLOC update by just looking at the first page of > > the vmalloc region. > > > > Signed-off-by: Shakeel Butt > > It's definitely pointless to handle each page with the stat being > per-cgroup only. But I do wonder why it's not a regular vmstat item. > > There is no real reason it *should* be a private memcg stat, is there? Yes, it can be a regular vmstat item (enum node_stat_item). However then we have go over each page as node_stat_item are per-node and vmalloc region can have pages from different nodes (I think but let me check).