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 91067C43334 for ; Mon, 27 Jun 2022 17:04:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20B0B8E0003; Mon, 27 Jun 2022 13:04:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 194938E0001; Mon, 27 Jun 2022 13:04:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 011118E0003; Mon, 27 Jun 2022 13:04:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DF5738E0001 for ; Mon, 27 Jun 2022 13:04:31 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A43A632CB2 for ; Mon, 27 Jun 2022 17:04:31 +0000 (UTC) X-FDA: 79624639542.26.B8A2AEE Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf12.hostedemail.com (Postfix) with ESMTP id 1E32E40034 for ; Mon, 27 Jun 2022 17:04:30 +0000 (UTC) Received: by mail-wr1-f54.google.com with SMTP id r20so14002131wra.1 for ; Mon, 27 Jun 2022 10:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ZvfkO3IFf3n/ZVC71sBF9P6CPQM5ABge97UmMt98ps=; b=MjiW4IZIKNvnRLaZM4hrpDs4I/vEqDj5/3xOzyG/gv8hlURBfdXynnwR5LA4UVW70b o6v1EJHUzimguE8TQT2qD+Ab522RK1leX7GKKUj72qeBt/3gTwNZo3T7zB5s5GAWR77C kmZiLNM8c8QVC160v7Ww9LlRpm1EKOj9ecAo/uAQCARN/f/mgZjude7rkreOk0yXGga4 Yc2oi4K5OYLJIn0wx5Z3wx0IbtNw5aTVQ4dxcBthCiW5NNtCuEvfM0Mj9ZlgHR8TiiCA U8V6ZkaLIF2+CvNbXCBVwy7P4laWgV05N1TKs+pMvPm7BtkXpcmeznV712/+QiAYbgHU HMwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/ZvfkO3IFf3n/ZVC71sBF9P6CPQM5ABge97UmMt98ps=; b=sT3GlvAVh7lLDQy04HehujtHWbJl4NDfvcj+MuajHZndA836WNPSw0R/b5bar3WVrT 8L8XfOrPjQkH4O/KFtw48sMFR8fSHRXzVXzAu4tOTlteGWm1919IV1WJBuR2af3nD/Gn aI/sDl+bPdxxR2uO5wnJG+yT/LNtWmww+/j8tzNrGRFXzN5PXuoOqup8zO3soT6FT23Z DZPS+nKB0Z/YoJb+g381SvLza5eCqhsxNWQzaBw2YoLhTol4eKnox/sWa5rKspfty0h6 uHm9SwNhizkOLj8WpGw0m/P1ui7TBz16NqE1fcX7bruaw0IERHApKODk6O8PK5q4w2qP 2MjA== X-Gm-Message-State: AJIora/ivd5Xzi7Bn3AwuC1qBaJxG9+jBBedOwmCz3tLBrezuzhyK0Av dUyKyy6yZEineiZA5Y3yWQj634zZcHnDw4YePt4Pag== X-Google-Smtp-Source: AGRyM1tsM6jtK4W1ydOvV8tE+BMi6c/Kd8ao252QMgYmdkd1sbM1VIU0dS/5S3UTvHRiwBpXdREowoHR7zHRMY+vfNk= X-Received: by 2002:a5d:6ac4:0:b0:21b:a724:1711 with SMTP id u4-20020a5d6ac4000000b0021ba7241711mr13037659wrw.80.1656349469508; Mon, 27 Jun 2022 10:04:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Ahmed Date: Mon, 27 Jun 2022 10:03:53 -0700 Message-ID: Subject: Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as memory pressure To: Michal Hocko Cc: Shakeel Butt , Johannes Weiner , Roman Gushchin , Muchun Song , Andrew Morton , Matthew Wilcox , Vlastimil Babka , David Hildenbrand , Miaohe Lin , NeilBrown , Alistair Popple , Suren Baghdasaryan , Peter Xu , Linux Kernel Mailing List , Cgroups , Linux-MM Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656349471; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/ZvfkO3IFf3n/ZVC71sBF9P6CPQM5ABge97UmMt98ps=; b=UdHYvIApTNRXrzfaxEteLmbwi47fJLsDv7odW3BbdALE2d6dZbHNCg0J2jjQR75mdMNNn7 TFYGbteQGUUGlgABBhsHQBWA41DMRBR0M7/NRS1nqquwDegwaxqFSKlPzLtMOckdpVpfFM 00gGjmbntYzYm1PdV4tGj48CG2b1tns= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656349471; a=rsa-sha256; cv=none; b=uPpzN83nQxshoSYTeTR1sAoOXUojs7wFN5JuSKXuktYgLvWmHaJcvtvLz5AUS5dHWfzZIu RwY/anfbkU8DNwDnVWdJpVIPbtLRnz5JH+WogpOT97fcRHRKr1zMPAuT+gBY48nd08f79V cFr683E4Hn4MKQ+vCqGPLvcsfMtClqU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MjiW4IZI; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MjiW4IZI; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 1E32E40034 X-Stat-Signature: e9bhc33ypbaqp68ktb5jbyp4rj3q1rsb X-HE-Tag: 1656349470-36799 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 Mon, Jun 27, 2022 at 5:31 AM Michal Hocko wrote: > > On Mon 27-06-22 02:39:49, Yosry Ahmed wrote: > [...] > > (a) Do not count vmpressure for mem_cgroup_resize_max() and > > mem_cgroup_force_empty() in v1. > > yes, unless you have a very good reason to change that. E.g. this has > been buggy and we have finally understood that. But I do not see any > indications so far. I don't have any bug reports. It makes sense that users do not expect vmpressure notifications when they resize the limits below the current usage, because it should be expected that reclaim will happen so receiving notifications here is redundant, and may be incorrectly perceived by a different user space thread as being under memory pressure. But I get your point that what the user sees as memory pressure or not could be different, and is probably already defined by the current behavior anyway, whether it makes sense or not. I can also see some userspace applications depending on this behavior in some way, either by handling that limit resize notification in a certain way or deliberately dropping it. Either way, making this change could throw them off. I don't expect any userspace applications to crash of course (because there are cases where they won't receive notifications, e.g. scanned < vmpressure_win), but perhaps it's not worth even risk misguiding them. So I agree that just because it doesn't make sense or is inconsistent with other definitions of behavior then we can make a visible change for userspace. I will drop the v1 changes in the next version anyway. Thanks! > > > (b) Do not count vmpressure (consequently, > > mem_cgroup_under_socket_pressure()) in v2 where psi is not counted > > (writing to memory.max, memory.high, and memory.reclaim). > > I can see clear arguments for memory.reclaim opt out for vmpressure > because we have established that this is not a measure to express a > memory pressure on the cgroup. > > Max/High are less clear to me, TBH. I do understand reasoning for PSI > exclusion because considering the calling process to be stalled and > non-productive is misleading. It just does its work so in a way it is > a productive time in the end. For the vmpressure, which measures how > hard/easy it is to reclaim memory why this should special for this > particular reclaim? > > Again, an explanation of the effect on the socket pressure could give a > better picture. Say that I somebody reduces the limit (hard/high) and it > takes quite some effort to shrink the consumption down. Should the > networking layer react to that in any way or should it wait for the > active allocation during that process to find that out? I am out of my depth here. Any answer on my side would be purely speculation at this point. Shakeel, can you help us here or tag some networking people? Thanks! > -- > Michal Hocko > SUSE Labs