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 CE08FC43217 for ; Fri, 11 Nov 2022 18:24:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1D3B6B0082; Fri, 11 Nov 2022 13:24:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ECDD56B0083; Fri, 11 Nov 2022 13:24:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBBCA8E0006; Fri, 11 Nov 2022 13:24:39 -0500 (EST) 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 CEA696B0082 for ; Fri, 11 Nov 2022 13:24:39 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 60B93401B3 for ; Fri, 11 Nov 2022 18:24:39 +0000 (UTC) X-FDA: 80121987078.20.1842D7F Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by imf26.hostedemail.com (Postfix) with ESMTP id 16B5014000A for ; Fri, 11 Nov 2022 18:24:38 +0000 (UTC) Received: by mail-io1-f47.google.com with SMTP id p141so4121231iod.6 for ; Fri, 11 Nov 2022 10:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=VFgOYEQ6NOhR14F+o1liXDfDhEK9cBQJ7rg815eUQn8=; b=N6wKqF8yyEt+Eo6I+YHl1q4P0AiwetFsOZQGEI+Xq9xFJz0aQPV1YS8smiPR5fq8tw 8HGxIaRNTcgdsULpAgSBfAUzKw8X+BuKmgrdfJVjEZQA+daVSKvyPziVjoG3BnbNalFi KI0TIyRwmMMher+y15JVLg9Z8qiY8H+LIcipf2u8ithG+kYyKO9EdAXW06OY0nd5SzgF UlIuOHYW0oFo0Bc3iS6P5+JiFMwHDodZekYcXrSE8DGpNm3CHtc4jK7j1WlV1VJRrUYG 77YuD/S6xG4OWiHiPDMxXwbDs/+4RHBwiRn22XPv7C7r5aBO6sac4kB+aRprIyoHee8Z isaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=VFgOYEQ6NOhR14F+o1liXDfDhEK9cBQJ7rg815eUQn8=; b=B6R2+u9nehkiHWhhX2eRH42tOYgwA6KSuAdTwKfyiautauye9tnuBhuyBMacXDwnlL LM99tilhP2VZJU6KQZhjsq3wmkQqzLAz2TNzaV0T5oxyEKehI/dVDU+gXxt8X3T3qT37 LBtCWkNE8diNSIoHwE7DFnmJD59Hho4324Z0Kgg2+DfS6o3iyJpx10WKgZSiY5GeHOvv QYKqUcc940y3B2GI2xcHB/HjHg2Xbyhk1LDTziY8vebCVJXjTKoPZqJVKJvT7pk24zrJ 0Ikj8zqeYUYlsTkgi8hxf8M23ndoeD9ebv5e2Y80m+NCIiOOSrzU2FKm3QJoISdqM5s7 0BtQ== X-Gm-Message-State: ANoB5pmfBHZwv4RFm90SjIn1AKDemRxih6mIJ0+ywt2HiA08XHnrHA3f T2AQwKSLTYvsgGv8dCLKc870aLUnoBn6RtgWd3Yk/A== X-Google-Smtp-Source: AA0mqf7qknZ+eornSMASLh6oCDao/i148IgoUZYiERYHbL/Nz3MBkKbo80KCtpDP4lzDoUMwcBeMK5Hf6NIwI18e7Sc= X-Received: by 2002:a02:2b10:0:b0:375:1ad6:e860 with SMTP id h16-20020a022b10000000b003751ad6e860mr1381798jaa.191.1668191078126; Fri, 11 Nov 2022 10:24:38 -0800 (PST) MIME-Version: 1.0 References: <20221110065316.67204-1-lujialin4@huawei.com> <20221110144243.GA10562@blackbody.suse.cz> <20221111100843.GG20455@blackbody.suse.cz> In-Reply-To: <20221111100843.GG20455@blackbody.suse.cz> From: Yosry Ahmed Date: Fri, 11 Nov 2022 10:24:02 -0800 Message-ID: Subject: Re: [PATCH] mm/memcontrol.c: drains percpu charge caches in memory.reclaim To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: Lu Jialin , Johannes Weiner , Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668191079; 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=VFgOYEQ6NOhR14F+o1liXDfDhEK9cBQJ7rg815eUQn8=; b=JlFREvqIyNj2j5CY//mA3JH2mwFqzh6As8haGEgiJw5sZv9n7Sc38ul07TSaPP4wA+iwkt dpf0b7c+axic+Umt5C3iYpwpRpUV8RBWCaZhYxvTg65OI8Nokxx9B5Kg7t2bqwlSeT3xzT Rt35P5Es3Bz/x1L38pQXxrKekIq/qoc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=N6wKqF8y; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668191079; a=rsa-sha256; cv=none; b=Qm+hGcEz11VIhtX3WutPBJuBuVf99uXMXMxD6Wji4K0oymLwG7wt+FLwmLmknL5RtoTtmb 25HF6xk69zDmKliVRAysZxgapxHszK8pWrzKlvO/Y7j89Ar+PcVWa1exDdJIUPoLORIEGW gvJgdUYAvjGMrhIeZx+G4nsBff7PUsk= X-Rspam-User: X-Stat-Signature: y7ny5hhtn1h7hr88e9a7eoan6ep8os7i X-Rspamd-Queue-Id: 16B5014000A Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=N6wKqF8y; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-HE-Tag: 1668191078-340407 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 Fri, Nov 11, 2022 at 2:08 AM Michal Koutn=C3=BD wrote= : > > On Thu, Nov 10, 2022 at 11:35:34AM -0800, Yosry Ahmed wrote: > > OTOH, it will reduce the page counters, so if userspace is relying on > > memory.current to gauge how much reclaim they want to do, it will make > > it "appear" like the usage dropped. > > Assuming memory.current is used to drive the proactive reclaim, then > this patch makes some sense (and is slightly better than draining upon > every memory.current read(2)). I am not sure honestly. This assumes memory.reclaim is used in response to just memory.current, which is not true in the cases I know about at least. If you are using memory.reclaim merely based on memory.current, to keep the usage below a specified number, then memory.high might be a better fit? Unless this goal usage is a moving target maybe and you don't want to keep changing the limits but I don't know if there are practical use cases for this. For us at Google, we don't really look at the current usage, but rather on how much of the current usage we consider "cold" based on page access bit harvesting. I suspect Meta is doing something similar using different mechanics (PSI). I am not sure if memory.current is a factor in either of those use cases, but maybe I am missing something obvious. > > I just think the commit message should explain the real mechanics of > this. > > > The difference in perceived usage coming from draining the stock IIUC > > has an upper bound of 63 * PAGE_SIZE (< 256 KB with 4KB pages), I > > wonder if this is really significant anyway. > > times nr_cpus (if memcg had stocks all over the place). Right. In my mind I assumed the memcg would only be stocked on one cpu for some reason. > > Michal