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 E1E5CC433FE for ; Fri, 11 Nov 2022 20:30:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FA668E0010; Fri, 11 Nov 2022 15:30:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AAA88E0008; Fri, 11 Nov 2022 15:30:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 372B18E0010; Fri, 11 Nov 2022 15:30:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 27B868E0008 for ; Fri, 11 Nov 2022 15:30:59 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F209A120435 for ; Fri, 11 Nov 2022 20:30:58 +0000 (UTC) X-FDA: 80122305396.12.56C4F46 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf29.hostedemail.com (Postfix) with ESMTP id 3D6FE120009 for ; Fri, 11 Nov 2022 20:30:58 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id m14-20020a17090a3f8e00b00212dab39bcdso8724816pjc.0 for ; Fri, 11 Nov 2022 12:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=kn0Y+63FiU6va/fYBfDM/PWGy/IsvE7/E02gtmFvSYk=; b=LauIKZokprmiYiUpRTowA0fVwRhG1sb1N7oihtbcgMA7TwP9eoVi2520gPrIFZep7S pJnuHLwnDF2VDM9eUh55VHUYnGdkEFidW9/9bsNhC/qNPgf5eX6F0ZxcVaMrWioEO11Z fa5qR7RTnoLcaQeazMfqpw8iB6MHozM45QG6JrYFvfBOdc0XVnsHZcd16DoWgcdHSSln 8az5drUooRNM39glR86z3JAW8CGKXl1Kw2nESRhfwUmp1h9lUnClNjf9EHo2ndngSttk n3MNlcC6AFIU5GIrmmoz6H9ekRsAIuImchViSew+lYdowbE8L1q+rheJT/HmOLIAP8o7 NyUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kn0Y+63FiU6va/fYBfDM/PWGy/IsvE7/E02gtmFvSYk=; b=SXqxPSQ1UUVXBl9PRCWB8nNTRA8bPYmg4ve+c5/2S6/yLiJb/hYMnISrDCZ2KnIrf2 idrKyTAbkJXXhUY8UBRQ88UAci73JsRTVglH8DYisr1TUmdvv/kqyhBeUogoXg3cObVw +tzuqFVkOsbSduJkD77XIhQs/GavAxYkOc5vYko5tKmWh2F9ocdRm2bv8/VpSSrnBEVu LrcLbwKb/80e2oCPdbSgJ3feEsB/VZj4mYOHCvD8H+ZelvUqXsEFuSOc64D9pwq4ZXyS A05CeZ+uDH+FMfyM+oEL7eB2Nglu3czvCJ2FnmfNn6rroypkpYU8cEpWGa4po0jUERzE qV2Q== X-Gm-Message-State: ANoB5pmpmjWPX2QEM02E6n+ubOVJsXbrGZFGk4MSB+/blKBpXnCBaDtI GavD6FgnMBtkRpfIP+df++TC7w== X-Google-Smtp-Source: AA0mqf7CqYdnrdKJ1pWR4K+vZFpqBWn89jr1KmO9yQwHlIQx9KE98fE1wHs7/5adGaOYMdzGC9Xk1g== X-Received: by 2002:a17:902:bd0a:b0:186:aad0:6b32 with SMTP id p10-20020a170902bd0a00b00186aad06b32mr4187678pls.77.1668198657032; Fri, 11 Nov 2022 12:30:57 -0800 (PST) Received: from localhost ([2620:10d:c090:400::5:54c6]) by smtp.gmail.com with ESMTPSA id 34-20020a630d62000000b0046feca0883fsm1698177pgn.64.2022.11.11.12.30.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 12:30:56 -0800 (PST) Date: Fri, 11 Nov 2022 15:31:00 -0500 From: Johannes Weiner To: Yosry Ahmed Cc: Michal =?iso-8859-1?Q?Koutn=FD?= , Lu Jialin , Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm/memcontrol.c: drains percpu charge caches in memory.reclaim Message-ID: References: <20221110065316.67204-1-lujialin4@huawei.com> <20221110144243.GA10562@blackbody.suse.cz> <20221111100843.GG20455@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668198658; a=rsa-sha256; cv=none; b=MRxDIjMYeDXuOjPHr3tATNBCLVYKCIrBObD7bFasCyNf5vBRqFFsyNbwjrZGEtlfGatIa+ M+lPpBtyFIBMLyea27ltInRWvted9vRjdbZVmQlsoy+11iQjQho3j2KfDb29/8MEUldspA havsDz7SWyy/o4K63sr3gK+GyW6k2rg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=LauIKZok; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf29.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.216.47 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668198658; 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=kn0Y+63FiU6va/fYBfDM/PWGy/IsvE7/E02gtmFvSYk=; b=LqIntQL8FLJCRoisYB0pjel0sSKz9OX6nNjYz5AueVKDruOYIWL33nXnwEGGxsnKBwU+yP HSEylKa5VuWBasPbxCZyetIiUp4QUyvtgMbVfAWWYsKtfYiUCMOb2+nPlMgyJri49t0Swb o+b85JXRjCIeITL/T8T0GSsMQqpDK8M= X-Rspamd-Queue-Id: 3D6FE120009 X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=LauIKZok; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf29.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.216.47 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Rspamd-Server: rspam06 X-Stat-Signature: bk4kinm79bfifwnbfpkmywnqikp695wj X-HE-Tag: 1668198658-840875 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 10:24:02AM -0800, Yosry Ahmed wrote: > On Fri, Nov 11, 2022 at 2:08 AM Michal Koutný 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. Yeah, Meta drives proactive reclaim through psi feedback. We do consult memory.current to enforce minimums, just for safety reasons. But that's are very conservative parameter, the percpu fuzz doesn't make much of a difference there; certainly, we haven't had any problems with memory.reclaim not draining stocks. So I would agree that it's not entirely obvious why stocks should be drained as part of memory.reclaim. I'm curious what led to the patch.