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 9C3D2C4706F for ; Thu, 28 Dec 2023 17:44:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1B2B6B00EA; Thu, 28 Dec 2023 12:44:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DCC386B00EB; Thu, 28 Dec 2023 12:44:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB9816B00EC; Thu, 28 Dec 2023 12:44:51 -0500 (EST) 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 BA0CE6B00EA for ; Thu, 28 Dec 2023 12:44:51 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8DB95A00EC for ; Thu, 28 Dec 2023 17:44:51 +0000 (UTC) X-FDA: 81616952382.22.DE0B716 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf23.hostedemail.com (Postfix) with ESMTP id C86D9140023 for ; Thu, 28 Dec 2023 17:44:49 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SEaIsckY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of 3ELSNZQgKCOEVKDNHHOEJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--shakeelb.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3ELSNZQgKCOEVKDNHHOEJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--shakeelb.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703785489; 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=65JQ/neOF7E3BZSaK6HoyZ6K6WgbLqHeOrTyvZc9PLU=; b=3xXmagkPEsO8PcG0JqKCqQQ8h/8SXSKKau+FXS8IS+M0xbD447hrQ3ZtjgKwmxmGjc7xaj cYj8k2uzGRR60okwIq27FKok6jlabO85vYLONrCS6FDhd433rZtKQWvnCU4wAeCCtLvtEx 7n7ltGTlWeyTdzFmGM19tY5jh0DqTQQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SEaIsckY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of 3ELSNZQgKCOEVKDNHHOEJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--shakeelb.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3ELSNZQgKCOEVKDNHHOEJRRJOH.FRPOLQXa-PPNYDFN.RUJ@flex--shakeelb.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703785489; a=rsa-sha256; cv=none; b=RKmpqYCa13ANXd7uwvCfOpDe2NjgEl1Z6I+GGOv0ibJln2eQ8GX8MBViUZ6FoRllu7zXCv zybXxxDXFXo+j8gTyX61L4uqhGiD1H2ceEWtgZRgU4bH0L3WIwDYkS0pwjbtD4bCATrHkZ WyVees3aiZgC7DC/aIjBi/obFozR8cU= Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-6d9af04a0d7so1377795b3a.3 for ; Thu, 28 Dec 2023 09:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703785488; x=1704390288; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=65JQ/neOF7E3BZSaK6HoyZ6K6WgbLqHeOrTyvZc9PLU=; b=SEaIsckYIWHr0UFkGNNrlGOPWYvnJe38EMwF1dtWLz1Glh4JzYZQj14D3I99ODEQNf mCulgahMTUOIiL/enbiBvpq9pknGUZr963urzE9ewcDjJhNWk5pAOITHBs6jpvvmywSI ncPvCo00a4DU24w0Ydf/TKOjPqHSdMR2YDq50xo8+yWTUekbtlPR2/TvuGC04QgKNz5W /j8ENNjiFmKYO5zGvL872wu9PYXQUZZ4ZiUUXxv6Y52HRBzrrfoOTHlNDI+9JMKWxgQo uba3tqgk878F2uv2+87DQoNCykeCIbe0g0PHxx4E50ovF7UZtpFvRuDlQ3ZKOjC0MIns oCmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703785488; x=1704390288; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=65JQ/neOF7E3BZSaK6HoyZ6K6WgbLqHeOrTyvZc9PLU=; b=U9cKWztNPa9saWiaMAAy7mj9iPMAxwFGQ+QtwDaafX4TgUdycVWdxI33p1iyquVlvW yNamhZrzmaiBiT8d7/TF2eSGLcYrAfntLLWnajnpFE3OZbKhoxa0Ya8KoWE1NQY1sqfU ZnQMYFtc5oCzgwoNd1V+EGGxH8idfXMZbGxQE/u+suKYVhYqx6ecPQClrNUr9zXiqPCh pkLMwX50QMaEg3n0R/mgNcviE8952Liy6zAG0mifXlIU935PlW4M5O0HEr+UfOpnfLWR h8CYb0yKzftNNbldniA3PQkCTtC/Fiewa55DsNSSb4hdJkkiHQPVPuHr3DL8+375plUg fDIQ== X-Gm-Message-State: AOJu0YzIDcu6l+BNqwu+376sRQLS6GxxA5SrvQNqn/GityvnXltpeRrk Txtp2FYje/Tr2zbHVxaFrFDL3Ze7hw50ffHD1hMK X-Google-Smtp-Source: AGHT+IFb2CXNnGtVi7vAiAt//7yCV6ai4yoXf39E1uk/GpboNY4ZFW1gXuKJl0CU1VDUIGOLxEfybw/xpppznA== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:aa7:8592:0:b0:6d9:f3b5:2d4 with SMTP id w18-20020aa78592000000b006d9f3b502d4mr22538pfn.2.1703785488525; Thu, 28 Dec 2023 09:44:48 -0800 (PST) Date: Thu, 28 Dec 2023 17:44:46 +0000 In-Reply-To: Mime-Version: 1.0 References: <20231228073055.4046430-1-shakeelb@google.com> Message-ID: <20231228174446.6jakusrp7272y3ze@google.com> Subject: Re: [PATCH] mm: ratelimit stat flush from workingset shrinker From: Shakeel Butt To: Yosry Ahmed Cc: Andrew Morton , Johannes Weiner , Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C86D9140023 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: gtxsthyaobmnm6tssb3b6o3d8rwaoqx9 X-HE-Tag: 1703785489-39209 X-HE-Meta: U2FsdGVkX194rzQoG3HOJoo6pcF8yl8WZ4Zo2kmXlO57/9v9RZ80NdR1HtZ5FXH3yNahq4YovWy1KUyVwHDn3+fnWQxEkuWqh7RlACf6FR/cH8onM1xgcKP0kZcT6fGdaB0WJVAu5ZzfevIrcRAd15Op14DXRWnTBiXNH8MvRykUkPjpnWYIxhflBD13ZTSEqbF3K9CVVt05d67TH+MjjMP6QqFMBpz6GTiRklWnDCh+aPBeWu6qPqaCpEnMg6BThIaUCtv4BbsX3xWgI3tj+IqgsYnLDb68xKYTZtDeCWGJ8SRX6KLXks5pFXfKCW1FGOPa8H/OQ1n8UnMe/VUvNG621QP8B/thKp6M8b7iPHOSOcwvzgkonHCa9Axjxwn3kNDO1nMkVWCgDmf+x/uEMNUWQZOa31+LnTtJOtXIrMEFVtb9ENZ5XjB5avoCS7S9RYKYMMQpWhQ2lq5EaNcCMEzLgIqL2P2bWcv6i1L9qjpIRayxRd4wwwjcCkj7V8jnthL2EBI+OmKpPpHbAUTrXrAWRtYwgFkpzfPrPUV4EhFqJE0Y8xSB0VJ5H38cO6lukjMsNvMEieLC9vnN92meL/E1TTLCxpSaTTt+EIz6/WynHqB/8JRJj2cjFF7CQolv16Yv7YUi0HNU2M1EZimL8+3TozNTIlY83MV/eZN60TpVB+Lz+TOJerbnfKc9lvfgjiklA9IInjaCaz3cYB+2tTZAZ1tNrL7c6Vod0YaBs4N3ToUWleEeb7KS35R0uNSopJo9IW+DezuFFUTxu8N9Aj2bcfS+KdU+yGk246sN3J78/ySMSwTdwroTO93klAjvCX6qsookqYqNYXH8sgxOqhkrNzc18C/cRyYJdY9ZqSb9rU2v+un8rM/TQs3F9S/8dfAN4FyHkY8QoLMzeqhwgbxaJx2sjJl7h97N3Shfbo5PJolK3ggcM5tCcQvnJ9/K1kT9gxnVw5ZWdzJy5BC L3/pjjGJ zk/qF9Slo4+2qFQlhU7rCNHGMB+P7orwbzJcPSdBdycibsY2NJNQGMHYf7YdKrvSbHosMtdyUocEdu0kyWTcZLDE0NushwhIJRR4+yIJkb5yYY7ED8FymGQqIVRQndjrrZZkoRsRdvTnmtu73NotVa7/MW031O1itGnFfgg/k6VocPlZy4jKPKhmFL+GJq4EOJSnx5hvzfyDHOPhBGOVT6L9pNLOaTruOjCzsViySPs/yENMiPH2QoLNwPSedmDU02dQWl0dBU484tO4DI2U7C9z9BHxL8w91o21fM6V6B2bHjnu2HICfjW3Us+E7nqZdBv9Vxha+jF1JXQf6xwZrXLpsJRH1uklH0CoYfUg2v5NLwiymq+c3Dx/Paz7TK/maQX93ihZZYpYCVwcikMHOaRdWxG2k2AnUYfuinwI3FJFi/u0LsIELItg2OQdHYzwLp7QXwIDppmxr7lnVVtzkJQ0xd/Dt4ZURMYup2Ptq+mKSW/GPUT6RjIKrh/9Yymno9OKHbkaIQ6XN9mqPmNyRxxZxqtZQbrm/i5g684A3l/qZh61WnU6mKxL6N6g73vU5a1ytw+pbmIcoPVRDj5FMFj6w75skaPprXBUOgZLbfihmp1m/saWQVCc8kA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000934, 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, Dec 28, 2023 at 07:13:23AM -0800, Yosry Ahmed wrote: > On Wed, Dec 27, 2023 at 11:31=E2=80=AFPM Shakeel Butt wrote: > > > > One of our internal workload regressed on newer upstream kernel and on > > further investigation, it seems like the cause is the always synchronou= s > > rstat flush in the count_shadow_nodes() added by the commit f82e6bf9bb9= b > > ("mm: memcg: use rstat for non-hierarchical stats"). On further > > inspection it seems like we don't really need accurate stats in this > > function as it was already approximating the amount of appropriate > > shadow entried to keep for maintaining the refault information. Since >=20 > s/entried/entries >=20 > > there is already 2 sec periodic rstat flush, we don't need exact stats > > here. Let's ratelimit the rstat flush in this code path. >=20 > Is the regression observed even with commit 7d7ef0a4686a ("mm: memcg: > restore subtree stats flushing")? I think the answer is yes based on > internal discussions, but this really surprises me. >=20 Yes, the regression was on latest mm-stable branch of Andrew's mm tree. > Commit f82e6bf9bb9b removed the percpu loop in > lruvec_page_state_local(), and added a flush call. With 7d7ef0a4686a, > the flush call is only effective if there are pending updates in the > cgroup subtree exceeding MEMCG_CHARGE_BATCH * num_online_cpus(). IOW, > we should only be doing work when actually needed, whereas before we > used to have multiple percpu loops in count_shadow_nodes() regardless > of pending updates. >=20 > It seems like the cgroup subtree is very active that we continuously > need to flush in count_shadow_nodes()? If that's the case, do we still > think it's okay not to flush when we know there are pending updates? I > don't have enough background about the workingset heuristics to judge > this. Not all updates might be related to the stats being read here. Also the read value is further divided by 8 and manipulated more in do_shrink_slab(). So, I don't think we need less than 2 seconds accuracy for these stats here.