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 4163DE82CDE for ; Thu, 5 Oct 2023 09:31:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5996D8D00B8; Thu, 5 Oct 2023 05:31:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54A4D8D00B4; Thu, 5 Oct 2023 05:31:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4114E8D00B8; Thu, 5 Oct 2023 05:31:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3304F8D00B4 for ; Thu, 5 Oct 2023 05:31:46 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id ADC271403DA for ; Thu, 5 Oct 2023 09:31:45 +0000 (UTC) X-FDA: 81310890570.22.BEA4623 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf20.hostedemail.com (Postfix) with ESMTP id D508F1C0003 for ; Thu, 5 Oct 2023 09:31:43 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4wOKSjTz; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696498303; 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=cMC25rA2+eSQ38+uqF7hDw2RgHtjVxvyqr0ZVM2w5zc=; b=wXySTVtEhWOrBptFibzwWGraMje/cHrf1Fi4Ie7X744HYLKGwnp88dc31CxbkME5uTaLym Mi5d83r2uu+OC/y2+moKjZ4GnF5iR2g32N80/q6Ir/Fp8SYrs+bM6ZW00WwPmY4NdPCnbK Ay/xEARmrnrPa+JVwL33ollDZCxdbC4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696498303; a=rsa-sha256; cv=none; b=vG6NsyFw1vXb65bzeRd7d0UIsVXjwtjBV1dInvoLS7Ju9OdkNn8UvgyVs+PQ7H2wBjg0g2 4sBoxLxxT9r3vmieJIP+QkS7IyBtq/1QdubtQT4SEvgProtU/Tbw7z+WOlxMIdMj9BFEDz GptsgMFe7wgla+xFIXKRNHJtY18jXt0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4wOKSjTz; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-9a645e54806so139244966b.0 for ; Thu, 05 Oct 2023 02:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696498302; x=1697103102; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cMC25rA2+eSQ38+uqF7hDw2RgHtjVxvyqr0ZVM2w5zc=; b=4wOKSjTz3wqMZAP63KDISOcmY5PFD9anleIQgxqni7B0pB6YzNrqEz69h3PvaqD7wY ZTYwI/tyXC80i6kLVE82i+zKAS5XNx0UKWdZK4rVKV5wViUjchNFUEI90+GoQw2gclwf 2Z6Jod3Wj3sbhOQ0qTUtceFFC0bdPhDP1Naqu6sTWeubEMPvLS5+W9BCkiz5ir2pfx5i xpUdvx4o3G6fpveRrMcBRA4ayo1tTEYJrILob+sQTuCdKn6Sju227ZdW5hwS3WJ7mfJy EG7FFlAenIBnd7SDf0YWWCoys6UkLDD40bTqQ0yFPa1WjOKlXKKGJJt7/mmHPYzid1iu W9Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696498302; x=1697103102; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cMC25rA2+eSQ38+uqF7hDw2RgHtjVxvyqr0ZVM2w5zc=; b=vBBpjgcMvQA7vO9cWj0zs2tE4R5YzYSqvK1y1Q9lJqkBNeMG+nOz3IWjUS5bUX3DwO PxDxXZFIV/jXhK0trfZrEZx2QQ37waYtAI2C0gusJzQIZbdQ4vs+YjxyyckA1XPuZs5E TMw9exrgh1LUN5QlVnaBnle8wBrgXSS0+RFFGZVMhTMazkISZzGc3r4JYQbFe8Ay0sPr URKaiPxvffsgrOWVhpgLyVV3YUbBqXoB/u/O4O4DHUyuqh3mQX56Rnjr2QPq6KOiw5da yoOuXgTt3zPh9bJAXF3oNgtTJZA0ENvZLiX7dBAcpKUfOB27T1Fpe4gvoPFM5HDXJ1NV zh3A== X-Gm-Message-State: AOJu0YyKp4EieGo9PGJcX2q9N7Rfa3YDxbIIwrGJ+kbXzKSx4csO5dLk YRhadhOTkQv92pVQ5GVRh/9MY1Ved0WsjkWh7jxS+Q== X-Google-Smtp-Source: AGHT+IFfvio8FkYu9A9VOWWLqGaexnYgvqW5wAR828Pr5q8lKiX9PTomSKqU1PWWRDMboEdpS7d26vLr+P42Oq0I+08= X-Received: by 2002:a17:906:196:b0:9ae:72b8:4a84 with SMTP id 22-20020a170906019600b009ae72b84a84mr4025671ejb.41.1696498301953; Thu, 05 Oct 2023 02:31:41 -0700 (PDT) MIME-Version: 1.0 References: <20230922175741.635002-1-yosryahmed@google.com> <20230922175741.635002-2-yosryahmed@google.com> <20231004183619.GB39112@cmpxchg.org> <542ggmgjc27yoosxg466c6n4mzcad2z63t3wdbzevzm43g7xlt@5l7qaepzbth6> In-Reply-To: <542ggmgjc27yoosxg466c6n4mzcad2z63t3wdbzevzm43g7xlt@5l7qaepzbth6> From: Yosry Ahmed Date: Thu, 5 Oct 2023 02:31:03 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] mm: memcg: refactor page state unit helpers To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: Johannes Weiner , Andrew Morton , Shakeel Butt , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D508F1C0003 X-Rspam-User: X-Stat-Signature: 41fsr8yw69zxpismjoadydb7mq64s333 X-Rspamd-Server: rspam03 X-HE-Tag: 1696498303-51755 X-HE-Meta: U2FsdGVkX1+EB/a7fB4aA+7jnvwyOqEIh6Nhd6zD1q4V+AGnIZFAOlpKrqnSit7CKnBMh+wf13rS8gBn1UquLjzIgLCvPDK/fiv35W0tsvvSdr5H/EuGj+boaCVc8eWRFIyub0RZh6yVIfvJP1o9hxigkNhun7XQah5dkBPKonfOSSl6mMwUoA4wyczC2PFKKPBcx0y2uTMAtzrdeUQIZ9C5Xqdzdb9ATB8ldJCUFFhrVZijjaamgBqeIkXK6yARXZ3YlrQve3AwNCQ0ad4wWRDVpJfPIcOmTeuzwYNyZaEOR1j2OtkCM65tzwCt4hH13u7UMZNwtK+fSkrD5dGuUqHgX3k+3guB52W2hU5Wh8HM2psY6k5WAef/CfGVri4E5Rx3tjld4FZ++FYiExCSRr0tIYVlf1BMqHx9/dnHvuDufJgxYUe3xMbrgz87OdCPEdVp9bdD2tLJtgnk+EFOazNTlmkPpqmrGHDbjgp9jJlpQZOcJ6Bhba9Rhc3AC0SCKzQr2iAhakfQo5mW8j6XrsP+f0b8YRoqBZcNXYG5NrbF0V2PdnB3Z15I4Z2Dg1EJLtODud4jFKT65QZeZj0uJz5rCGPTBd/71mWXhY0MLlXXyVIgAsQTK+soAmxt/hyK+4TiedjldC8hD9noS4a689wzI+dzaNyMqimZ2VRfwelrLXIuckvcK2eoFDLW3911OG/Mh0+NQjteWWnow2b/SRl34oxX3uFVgMcPh2HEnC08BRcChLtuEwY09XvI6OnRi74Cd3ie5plR04b6oNDOvbkNunDJmnfQMQtI/mbQwIZObWkeaNobQtpbwO0vxigFsUUiBSQDgnJtUOL+aNwBu7/2bEBeSzlqsvzxj5hoRZXtTccjh6WdDej78QafVk9XtMesUJPo6TWdg7ICL/ms47X4C2Tytjs8SffOkK5ebYU0FnsAEQXs2Oca18ah/32unYJ82ZK55/JEujumlSr OGI4vdMM jppYtYeqAX0dLfvgj0M8NsueowjmraMiySjWXSu9K4yM/cfssTFmLAfdmbbSTDRduQjsr13EN++SI8ogvjtbXuQY3tDDm8LEKzLARF8cxknRxh+mL52dKsdX7S7p19cYYu27ClWwNC6oEHPoPRaQkbNo4dSXhjEoAmiLNqsHZAITIVXicFbgygIpy6/wxvCu0qDdVVxfkUIi9b2JLdfz7yVfvhCr4Ju1sTcgCpw5mjw5wbEzw7fPyXjL5d/XkBS6590uTYmhKHXAxw4E7unxbWARBh1ddBf6D28vqHnu0P3B6pkA= 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: On Thu, Oct 5, 2023 at 2:06=E2=80=AFAM Michal Koutn=C3=BD wrote: > > On Wed, Oct 04, 2023 at 02:36:19PM -0400, Johannes Weiner wrote: > > Yes, it's because of node resolution which event counters generally > > don't have. Some of the refault events influence node-local reclaim > > decisions, see mm/vmscan.c::snapshot_refaults(). > > > > There are a few other event counters in the stat array that people > > thought would be useful to have split out in > > /sys/devices/system/node/nodeN/vmstat to understand numa behavior > > better. > > > > It's a bit messy. > > > > Some events would be useful to move to 'stats' for the numa awareness, > > such as the allocator stats and reclaim activity. > > > > Some events would be useful to move to 'stats' for the numa awareness, > > but don't have the zone resolution required by them, such as > > kswapd/kcompactd wakeups. > > Thanks for the enlightenment. > > > Some events aren't numa specific, such as oom kills, drop_pagecache. > > These are oddballs indeed. As with the normalization patchset these are > counted as PAGE_SIZE^W 1 error but they should rather be an infinite > error (to warrant a flush). > > So my feedback to this series is: > - patch 1/2 -- creating two classes of units is consequence of unclarity > between state and events (as in event=3D=CE=94state/=CE=94t) and resolu= tion > (global vs per-node), so the better approach would be to tidy this up, I am not really sure what you mean here. I understand that this series fixes the unit normalization for state but leaves events out of it. Looking at the event items tracked by memcg in memcg_vm_event_stat it looks to me that most of them correspond roughly to a page's worth of updates (all but the THP_* events). We don't track things like OOM_KILL and DROP_PAGECACHE per memcg as far as I can tell. Do you mean that we should add something similar to memcg_page_state_unit() for events as well to get all of them right? If yes, I think that should be easy to add, it would only special case THP_* events. Alternatively, I can add a comment above the call to memcg_rstat_updated() in __count_memcg_events() explaining why we don't normalize the event count for now. > - patch 2/2 -- it could use the single unit class that exists, > it'll bound the error of printed numbers afterall (and can be changed > later depending on how it affects internal consumers). This will mean that WORKINGSET_* state will become more stale. We will need 4096 as many updates as today to get a flush. These are used by internal flushers (reclaim), and are exposed to userspace. I am not sure we want to do that. > > My 0.02=E2=82=AC, > Michal