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 3C35DC4345F for ; Thu, 25 Apr 2024 22:54:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B11466B0085; Thu, 25 Apr 2024 18:54:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC28D6B0088; Thu, 25 Apr 2024 18:54:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 989C46B0089; Thu, 25 Apr 2024 18:54:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 779D46B0085 for ; Thu, 25 Apr 2024 18:54:53 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id EFB2D1C0A29 for ; Thu, 25 Apr 2024 22:54:52 +0000 (UTC) X-FDA: 82049560824.06.3FA7767 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf24.hostedemail.com (Postfix) with ESMTP id 31E02180003 for ; Thu, 25 Apr 2024 22:54:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E9g+U6Vf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714085691; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KFy0ruxkfrD7/51FiBIWLXNcstal7LfGC2Msjg4LiFM=; b=qLbUQRJMDg+RFd+wPOwNVotbz+PsvzK8xkrqCnmX0A591nX58lSPr4XpFdyy8IJVmyRE7Y qLu2UUqCZHxoVJtJ2TI1woU0y7r2lgsP4czP9DmJH/X5FYUNr9Kn9StQEkIdmRJVZBTiXA qrOF8wXOPzBxvwmIXfmHPeN/ufAFnpU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E9g+U6Vf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714085691; a=rsa-sha256; cv=none; b=8CjY9vM89k0wvysyh+9n7Yw9Gjq2gSaQhFZxz96Y1Rh/IfRWf7Xg2dECIiRCczlKuXawfN JAYdN8DJ57uBnh8q4QiQ4dWaN+kyVEEdAI9BEdN1lLU887QHU7HeaZ9/l66i5WETGGjh6c wrpEreeOia2i/EuJ6z4qJwg8rUrY2nI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3258861C39 for ; Thu, 25 Apr 2024 22:54:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4238C2BBFC for ; Thu, 25 Apr 2024 22:54:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714085689; bh=OPvPhadmnJkmJD6QVWg5V0EqAqVaZnNCxCAbiIxAbfM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=E9g+U6VfRi9yDSMuMhrxB1Mp9RXJQ1zLp0BKXAT5nk6Xma8ccQ32PgMLDssWa6hKh 7TPxaOLJtVGIigUsVL1JghFdKQ8uaMNYEeoCiRTzK3+Yb96rZI3fitdHiJQUm2nucm Ki8sb72fwIIU0pnCr5mNwwpr8IWz4X3vWH3vT7jMQjjccWc1LW3QGddl5eJwB2XBWa nUmR9AduiPk0tXnUuUCAmtP6cyQR4MiLE0N5rvRNJaf7ZHf6sJ1+ppjeemWfz9UYEQ 74M/0gp8GmAA3GyAgu06T/GoP6by2zKaAh95AgiseLQ77OpvSrw/XPGmPJe+e+Kbqm 6RbRjTaDVenlg== Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-518f8a69f82so1739488e87.2 for ; Thu, 25 Apr 2024 15:54:49 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUyPP0CFdUmCYbbVkCaoqtpJNc68hUSCXx+/a4erxnn9lQ9m+cZT88uyLTxhqBLyxzkSVbNj4lQATzQU7Hi4jvigAY= X-Gm-Message-State: AOJu0YxCBOF3ocSxiJfnLNX/xGSUJdMNW6+fEN38ofpTfcEnshzakJFM 5vGIfxlI43aAW5H7sHQOn/neOO9N5l7J+7Rt4k4xuWttkUdSZuFWZ9GBrat+aIW3R+BscKc4Wej DIysU8EBMyLUQW3bYAfDXduF6xw== X-Google-Smtp-Source: AGHT+IEzNchdscKAvQzaEfeLqV2MtTfOX1FBtT+6Diul7Ucds9LiUwJam7OKzowQ4uoYAO1BDl+WjpiKVErZ8caHUNQ= X-Received: by 2002:a05:6512:208:b0:51b:18f7:6a9e with SMTP id a8-20020a056512020800b0051b18f76a9emr463183lfo.45.1714085688498; Thu, 25 Apr 2024 15:54:48 -0700 (PDT) MIME-Version: 1.0 References: <20240423051826.791934-1-shakeel.butt@linux.dev> <20240423051826.791934-2-shakeel.butt@linux.dev> <20240423135844.GA21141@cmpxchg.org> <20240423183041.GA318022@cmpxchg.org> In-Reply-To: <20240423183041.GA318022@cmpxchg.org> From: Chris Li Date: Thu, 25 Apr 2024 15:54:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/4] mm: rearrange node_stat_item to put memcg stats at start To: Johannes Weiner Cc: Shakeel Butt , Andrew Morton , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 31E02180003 X-Stat-Signature: jsrhusytw8mbuarqnp87qf8jtjctsoeq X-HE-Tag: 1714085691-292808 X-HE-Meta: U2FsdGVkX182sVDgIuFKfsH5onsAh79cCCqEpdP/0Ql69KENZUHE+ChqHuZAPmM8Mr3JEDRyDQWz0cw3rg8G74dOzNXASnbKngpotPbyqactIfdcs9K28yor/2sNqkesBF14dDJyNjsGagnwD035j9l4qQUOCU5lR8j1w1nQU5XyCLQL7JEOF6oLJfM79s/FQUWvJPk3Opzjz4Yt1Qn3SgbeKtF2qPjK6z8j4o1HdYC8ocdv06X8OZsKeYICK7sl7EnKo8nf4dnAbryfe2jm49EAC4g3JC1inCQ2jjvyag/8e6r5nNz7Qz38qI8o3/Bzscmbkhzg5Y/jjfLE+DNSI09Y7v2yt5Nwp3+XlUv1k4Imqh+ZS+ms5E/zA4FMol86uAi0AmA1ZpjPuzh95x/rOeE+oRkrV3VxdLqbvQp+5XMphgDrbY7l3KCJtZUgnLV3qRtfnqytXs+ghOYmdPyqraEe1cEZ+Jm0tM3tSXa6c9ksWAFa2vUwYmT4NbF/h80jK3im7tWa7z+YEGfEsX/p9RH/sZRbZ0ydKmpLjpMKiDC3KLh+534xEc6p1zUPTaPZKiOPXWqTTlesQfF+T4wrLg+4eeOEzSBkB3d+o3Id+1dMq/K3X06iVulPcETRFQBNECivKJMxMJLk8ohWNQKAxHui0Z0kTvTpzuwY01B5u+fJ3wk796gD+eXVLUzMkHBpi/S4wYmIiaZk5dQR6fvid8YDIaOrcGH/ShYdrwJMtM9qf3x5+QW4/KyDce0qlTBpx/2hzxyB3Qxwy8B2LoZiqirmwWlCkRt9mSO3Q5QS7VSVdKxIamWN3gC1vlS2AHkU3tHpCcP2w+9tH7Qg59lBa/NnfClE4TZl4yLzAqbMcZmDMR1QpvPSu948Dw7H3qGEGA5BhKYjQjQRJeG4Ezqp0/hTKLUeJ0bb11LhZwjxsUx9JNzNKtiZP4+6j6RM7If0qDvmj+BZZfqlFB3CNzW Ayg== 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 11:30=E2=80=AFAM Johannes Weiner wrote: > > On Tue, Apr 23, 2024 at 10:44:07AM -0700, Shakeel Butt wrote: > > 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 th= e > > > > 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 paralle= l > > looking into rearranging fields of important MM structs and also enums > > to improve cache locality. For example, the field NR_SWAPCACHE is alway= s > > 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 littl= e > > bit here and there is fine unlike what I did with this patch? > > I'm curious what other folks think. > I slightly prefer not to change user visible ordering for no good reason. It is not said the order is carved to stone. It depends on the ROI. > The cache optimization is a stronger argument, IMO, because it > directly benefits the users of /proc/vmstat. And it would be fairly > self contained inside the node_stat_item enum - "ordered for cache". Not sure how much of the cache optimization is measurable here. I suspect it is going to be hard to measure a meaningful difference just from the cache line order alone. > I was more hesitant about imposing a memcg requirement on the generic > vmstat ordering. That is a valid reason. Chris