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 D7E5FC4345F for ; Tue, 23 Apr 2024 17:44:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E4C26B0158; Tue, 23 Apr 2024 13:44:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3950B6B0159; Tue, 23 Apr 2024 13:44:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 283676B015A; Tue, 23 Apr 2024 13:44:18 -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 0B3B96B0158 for ; Tue, 23 Apr 2024 13:44:18 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BA3ECA0453 for ; Tue, 23 Apr 2024 17:44:17 +0000 (UTC) X-FDA: 82041520554.17.50FC899 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf12.hostedemail.com (Postfix) with ESMTP id 2A6C54001C for ; Tue, 23 Apr 2024 17:44:14 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=svG1WfsP; spf=pass (imf12.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713894255; 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=0umvTxHpcw152hw4GNh+8AkQo7OLhcip+cLOCx1NbGs=; b=WefJgtn5G8Ks0MGrtKknCzv2nhQ771cFRAW5/GKN5iUy7w63zSpu2W4jdunX0cWkiCpc6x sdXxYvE33GmhIOXOx50elvgm3zfPAKVVKgMCxikvVzs/6+3PCBhM3J/Ja9c3UWW1RBh8g2 UNQUw1rIDgwTRPXk4zCYfiy5243IMjY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713894255; a=rsa-sha256; cv=none; b=yng1coMuYTjEEZq7VN/ZVB5vCFr5u6bC9wAqsH1d1lSgH4WtNBGO6nPI1CwHMlh+w4LUtV qmxVB4AHWPhf4EUTEJ6rBSwTmKUOMINkZhHJ/55pDi459h8cn7QDT9IFCwVMGknN4A9XfO DKKjjD4c0dxFwVvv5iyRW6tTnb/k/mE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=svG1WfsP; spf=pass (imf12.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 23 Apr 2024 10:44:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713894252; 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=0umvTxHpcw152hw4GNh+8AkQo7OLhcip+cLOCx1NbGs=; b=svG1WfsPjl+c6V/lE4Win9SUPatCmd83Kj4ieN9i6nN+1YS8YRtaV6beXQbnFEzx4D8w8Q jn6qC9uOmtMyTzE3TMd1dwUa0fmck+x2iNyWdEw9X8z3olK3LPuj9KTWJ5Ff4OBeig89k9 hXBEJohiG4HWeOiGMW+bosjdY6OdRhA= 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 , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] mm: rearrange node_stat_item to put memcg stats at start Message-ID: References: <20240423051826.791934-1-shakeel.butt@linux.dev> <20240423051826.791934-2-shakeel.butt@linux.dev> <20240423135844.GA21141@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240423135844.GA21141@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2A6C54001C X-Stat-Signature: 31icwjmeaqcxjnjggkq9hka8btryx59q X-HE-Tag: 1713894254-779911 X-HE-Meta: U2FsdGVkX1/HzMYfZg8q0SM+QARE5phoXelFr0/Icc17Q2nbZ/jUyLVlOKChXQ7EifK+XwrOZihethXc/l25NNs/GYfgMJlQgXU76hx/bb2/WJogKlZiZlFNCXZmNiSWayNAFTwyDm9MbNTgdSBW1PM4LZEJmlPVa4Ju5F+XG+1q6/Q2dsJEmrHBiJ9qQXPM0fPVrfwN7znNL6o/5RQI49Mj7VUe2kCmZxeQcW4vfswsdAT0n/66RJ170CAbGws4158bldJy8fnXc4KxD9oIZf3E9bWsOjU24oNJPPQy4gMnVCMs1Ju4XBhyLNm/fb3V4H1Eu8JAIJaW8iZziu0Jnb+afOcfsyzZFmBtNe+hgymIE65kTnBs7+uXKszsGUCXorStoUb57rrEDRUKmxmBZidxquR81tYZV7c8f9lMU+AEglQSbExEM7OgM/fV5oLZVTeTGz+DA1Ot/gKaplwMcySrYCQV5nU5BCvRuBDf1s4j7haz2vMYcP0szSxkmO9KJymHifHk+FAetdjSURmQzRwsZcrNo9xOsV5AGral4I4ZCUo+yI6vcNcl6jjL+i4O4DAyBVkNXZ3sTKz7MViTPxtE7UJKkPe8HWUsO80ZKbdcxDhXoxz6jQAcZBvNkwo8P6V9jHGTbddLd7CHrr3W0CzjHf6VwRQ4rTczswBcF2/Vj7VUYhSakbHtYC5Kvbqdz0Cq4qSknXlv+zahcn8pojMwoIGPXUXnnoHFseeOig8YqdNFAG/SUeA29sGntVxvK4LlXGYfZF5B5ZarrhQxpO1yFS291XcvD/PqpNGJM+Ry/7lwjULF5kmxDNsiCdI+fdkXVkG52aA36/VVExK75A== 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, Apr 23, 2024 at 09:58:44AM -0400, Johannes Weiner wrote: > On Mon, Apr 22, 2024 at 10:18:23PM -0700, Shakeel Butt wrote: > > At the moment the memcg stats are sized based on the size of enum > > node_stat_item but not all fields in node_stat_item corresponds to memcg > > stats. So, rearrage the contents of node_stat_item such that all the > > memcg specific stats are at the top and then the later patches will make > > sure that the memcg code will not waste space for non-memcg stats. > > > > Signed-off-by: Shakeel Butt > > This series is a great idea and the savings speak for themselves. > > But rearranging and splitting vmstats along the memcg-nomemcg line > seems like an undue burden on the non-memcg codebase and interface. > > - It messes with user-visible /proc/vmstat ordering, and sets things > up to do so on an ongoing basis as stats are added to memcg. > > - It also separates related stats (like the workingset ones) in > /proc/vmstat when memcg only accounts a subset. > > Would it make more sense to have a translation table inside memcg? > Like we have with memcg1_events. Thanks for taking a look. I will look into the translation table approach. The reason I went with this approach was that I am in parallel looking into rearranging fields of important MM structs and also enums to improve cache locality. For example, the field NR_SWAPCACHE is always accessed together with NR_FILE_PAGES, so it makes sense to have them on same cacheline. So, is the rearrangement of vmstats a big NO or a little bit here and there is fine unlike what I did with this patch? thanks, Shakeel