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 D4F35E9271B for ; Thu, 5 Oct 2023 17:31:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DD108D00BF; Thu, 5 Oct 2023 13:31:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28C458D0006; Thu, 5 Oct 2023 13:31:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 107A18D00BF; Thu, 5 Oct 2023 13:31:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F0B2B8D0006 for ; Thu, 5 Oct 2023 13:31:15 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BB3141A0199 for ; Thu, 5 Oct 2023 17:31:15 +0000 (UTC) X-FDA: 81312098910.02.65F91FD Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf04.hostedemail.com (Postfix) with ESMTP id D0A6E4002C for ; Thu, 5 Oct 2023 17:31:13 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=aSKKjWi5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696527073; a=rsa-sha256; cv=none; b=0umQeNe4KeojqaErAGBobvy+4anzu00DgjE1tFrcVoC2oRvLfUVIBG2vBeQky3o2yqCWQU cpfMtFe69Nw7csLGMS4F3HlxYsDFAOl4UdrDyp+N15OmDbkC6QPXJ/byeBj3IGh9rsQbmK dmt0z6uk+nMseKhndQSOgBbHrmh7PN0= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=aSKKjWi5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696527073; 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=1memPM/vxBDQ1ObeKhzGvTLOKg7eQnb02BOsVR5S3is=; b=Q9ixi9U+0zi/6CBI0U/rUtgfQkbwIYKTWWFlCfyX/tV4/IBKcvXB36fFHkP4c6tNpuQir4 LiLKYidbu/tMQt7IBzwSFGBhaHUCUQ7hfGtQhgmPWtL+7RWsGQXQUh1Agj2W8qOpqwAJsF UDLW+SWGKt4GbqxeJsV3ACegmV/7/to= Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-9ae75ece209so240012866b.3 for ; Thu, 05 Oct 2023 10:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696527072; x=1697131872; 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=1memPM/vxBDQ1ObeKhzGvTLOKg7eQnb02BOsVR5S3is=; b=aSKKjWi50OdxDDYlEPJ8TUmSYX8kPYIMpGHL+vBkCBBP0u5WrYbokIiEMA8K3+iLba qY9FZHtQNw3DErx4qH3rzmc+bnHVACCv5ZUlEsoW+Ej13sltcnx+vhr52ZDnpMrYB7bx 51JTsq2KiQt10cl6w6APEEqD0YJ5RBjGLI/uUGwdWQPBRQKY1UlJXVkgzTtM3Ki9O84i UiRK6AEwn+3sDKtWItiHLhJLZ75OCx56LFsV09NO+LLR7lttnhA8mXy4J4zS2St0uPWs 2xr/Gms228D+3dF5EDcCQwUo5YzGPPdVQ0Qos4d6lRxZ7Wv09qNeG9+vh6U1Pc7xqTNM +8hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696527072; x=1697131872; 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=1memPM/vxBDQ1ObeKhzGvTLOKg7eQnb02BOsVR5S3is=; b=gicMHgh8I2XdIjEn93Pj9lRyod1mFZV3uatRf47YHvP2ZnEMv9r5oIq9WeZDtnhvM1 JM+hfJopFXrKtgo9qxWGew0I8WX/8JzuX1H4lHU7ItNpersoRGkHyPT+0mnBciSeMHGm fCK3yJAqi3qqiJGWV7EtLiRC+wIN+RSvkyHFfoKGlTisB/YvLZpphkpMHW9iiUdSvL6s 7LwrDHTk9SXlfmDmh8srZsqwbfoeAThvFzhAwQS6wMw/ExcXiIGzQYsQ8dbohYAbPVS9 PBU/ZASEf/ZJP4v+/y6AjlHjg1n95WiK4kw3UOMCwO7SX/9JmArObDLN7T81/fTWEjVW sHEQ== X-Gm-Message-State: AOJu0YwzrtvG1g0qZIpiotgucWGiSqGzZS3Rv6JtbKyKOAfgpCPlPThX n14EMEOFh/+FcBEFDaC5ulTasG2GdZ8Nvk3o//jrIg== X-Google-Smtp-Source: AGHT+IEL4DuC4ou8q35SZgnZsg9C0xl0WVzmWjTBKA09JsJKsmFjoBPQ+GWYLCFjWvyffBZGjdzuZu4/fxie0IehC/c= X-Received: by 2002:a17:906:7389:b0:9a5:b878:7336 with SMTP id f9-20020a170906738900b009a5b8787336mr6334195ejl.7.1696527072207; Thu, 05 Oct 2023 10:31:12 -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> <4h5uae72ti6jyiibcyfg2bytooy6d6ggtkrgod5a6rmpateyra@4setu5jmd5kn> In-Reply-To: <4h5uae72ti6jyiibcyfg2bytooy6d6ggtkrgod5a6rmpateyra@4setu5jmd5kn> From: Yosry Ahmed Date: Thu, 5 Oct 2023 10:30:36 -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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D0A6E4002C X-Stat-Signature: run3ksn4yqa4osuf8od6sfkquei37oa3 X-HE-Tag: 1696527073-910457 X-HE-Meta: U2FsdGVkX1+ATs4Q/iWehROYe82PVlFp8Qvignj0rzpsNf5DDIk7NszYMnzGv3L8gSYoA3owBZUw3lf+HhO/xfYFVTJPEW+lcCv+Bb4FZyIJMz8nd7IpQbwa+Q5hDXa9nvFrUSdjjX17owH5s53w/mOJkUuTNSMKWtso1kHiV6sRXQBcXpxp7zlIeu/xAoR5ssqm9vOvtGO7xzyR9dX08JEe5CkXJ14jRCpp71Q4QMSsUSqX9Hg5ZhR113apC8RGKQ8i+IlgXkKzjRajj8tGS+94afLA/a5lldn2ubE6qDf1QFbedVd2tICa9lWSIWDhsjyikElwnwTUyopCCtLoNiiBqxSjM5+rk+0c6ZYf/aBy/xhWUeNo1iizEcaUCNZKuXSd5ThrcaBKzCZYZwr8tDM54eFWRQUAexSKih9nmOOQbLNCYkHuJWNBqXgC1qgaMVmerN5vDvl1MOSLC6w/tlgjeFG8b/V+dYb0YzRE+FfmIP+2LvRsMRwvJxpNX5EvSSalB2SR9NXHtWZTZPQfVl4OHzE56JzlXVCttk95FKUsZLXzkgYF4aKonfdZxCTvMHjcL6lajJ/RNXA2Hv8B6AY0VTj4YxrbeKVg2OpySDXorSY/q2zwI0lIRUvdGD48LhTMWAHTJ+FdwNDhUxXEM9kiF9tm3WM6lu8eYaQfFVxO9M6IMKapLFBu4MdmorzLJDtYdhoa1saXKHBnhykI0/YC6JJuU+6SkMD9v9EIMCGC5FwAT8m0mDMnICWn3kx8D7EfreVTjaFAm1lXHi5V9BsEomdPXxbTwKlhTm/fKq/mBFOAbMBGOzeHS82r4ZaBkvk02S27af1aJapw0voykDxHo+nrxD1GzgbZy6QXTyYu/kMSmFZkQi15UiIuYC8XBeLeTK+DIo3q9ybbP/tGGzgJLiVikOBENtezr3N8OMlj1r4lD4w8xtjUiKKtU3FISFyXJW578/bPw/vbk4/ Clqj1u2X 5Z9mS7wagMBdrAXP2UiKXRjtY8yCKfOG0lQH8QOaBP4UmzojUHGy311oWyA/I+i4GUe6l1JadSZXokFfWvwEnGiT/6PzU4bFYgjQkUNMlGwIjFFCA6D21h1brYAXS9qSuNvH9gNy+3SPWNii+BM3g8NU4hLMvEkg/vH5qf1C4TDEWl7sBWKVObZnVEDMYxJPAXXUGmsu/2GOr5a+y1tNOFUN6kK3Jo+YtOC3imUNXHd7EdZ7PqJ+j/3Xo8Ws23v9t0xRa7U2kvutlaMY/gCvxoNMs7k/hwYk/YNkOO+k8u6i2KzOu3dtDx/I41g== 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 9:30=E2=80=AFAM Michal Koutn=C3=BD wrote: > > On Thu, Oct 05, 2023 at 02:31:03AM -0700, Yosry Ahmed wrote: > > I am not really sure what you mean here. > > My "vision" is to treat WORKINGSET_ entries as events. > That would mean implementing per-node tracking for vm_event_item > (costlier?). > That would mean node_stat_item and vm_event_item being effectively > equal, so they could be merged in one. > That would be situation to come up with new classification based on use > cases (e.g. precision/timeliness requirements, state vs change > semantics). > > (Do not take this as blocker of the patch 1/2, I rather used the > opportunity to discuss a greater possible cleanup.) Yeah ideally we can clean this up separately. I would be careful about userspace exposure though. It seems like CONFIG_VM_EVENT_COUNTERS is used to control tracking events and displaying them in vmstat, so moving items between node_stat_item and vm_event_item (or merging them) won't be easy. > > > We don't track things like OOM_KILL and DROP_PAGECACHE per memcg as > > far as I can tell. > > Ah, good. (I forgot only subset of entries is relevant for memcgs.) > > > 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. > > snapshot_refaults() doesn't seem to follow after flush > and > workigset_refault()'s flush doesn't seem to preceed readers > > Is the flush misplaced or have I overlooked something? > (If the former, it seems to work good enough even with the current > flushing heuristics :-)) We flush in prepare_scan_count() before reading WORKINGSET_ACTIVATE_* state. That flush also implicitly precedes every call to snapshot_refaults(), which is unclear and not so robust, but we are effectively flushing before snapshot_refaults() too. > > > Michal