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 9451AC433EF for ; Mon, 27 Jun 2022 08:40:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 152BA8E0001; Mon, 27 Jun 2022 04:40:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1037E6B0073; Mon, 27 Jun 2022 04:40:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F16FE8E0001; Mon, 27 Jun 2022 04:40:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E1FE26B0072 for ; Mon, 27 Jun 2022 04:40:25 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B52A21007 for ; Mon, 27 Jun 2022 08:40:25 +0000 (UTC) X-FDA: 79623369210.11.ECDCEDC Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf12.hostedemail.com (Postfix) with ESMTP id DDEC14002A for ; Mon, 27 Jun 2022 08:40:24 +0000 (UTC) Received: by mail-wm1-f43.google.com with SMTP id r81-20020a1c4454000000b003a0297a61ddso5573305wma.2 for ; Mon, 27 Jun 2022 01:40:24 -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=XRmJjWWFtnuNSlD/e9eL++RxDIH2gU2v0iOznKKFYn8=; b=Wuf9RiWGC4Ck7nVJZxIuaXqlmtEYZQSIQ/XU/Z3BJHvJoGLTwlZuqu5MCm4eK8t4D6 fSnBv50+/jxAWA+u1iNE8whVMBdy0DjEnq1FbrGKA0TR37/yl1d/wO9Ser1jFscjBj6c QW15NB1JthAErb3q383ZT/lBSAQVHiH11T3Z/Le9O3AL3nzdk2slefDkprcvlxggRPD2 E7zlM652mFNrNCuRTHdqzfs5qO/5QlGtZJh6nVcsRgHPMGrTLUPKgtqkhBYboGYjExQX +QMRShFRn4BvAwX0BPOX8fJsMYKSGCo62b1c7mA0RzQ1z5SYVxFCGQEWFZ0hVr9xMuvu eJ4A== 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=XRmJjWWFtnuNSlD/e9eL++RxDIH2gU2v0iOznKKFYn8=; b=uyMFCnd7Lqth1KlV+SOvenpSc6v4ddpDCunynSS5PTGYf9uOrR1Tzd2faOVAbDlD3D o/J2lOw+9cu07J9m/3VtEUNH+eF7oH85KhmZY3uiqpQcnjFGCZCYZX9VgS9pCWrczXyF cGGgXNpQ2UhJBPrPolNWIn8VGqteIbynXAXJgiOyb550RbLTd2SplUrUrlpijG8yP7Bc VtEgHaTNY/aWVoVxJnBwQta7R7/tE+WGrQi1YDEiUITo6uylnOvrn29KB9Sl3QOrIIL0 zLumCxNFrUoPJfFWz6yxBR3hiHHIrtVJHOTOQWuu5hNInK30Ro9/FfbiHvP1sLEi3izJ M4dw== X-Gm-Message-State: AJIora/nThvIbe9v4EG8qa+JMJYAhrpyElSVvTGo5ZGG99qNSkRbTYbv Te0rmYFmQO2kYnSLlup4HIaci6n8PUTrrCRwxhgK2A== X-Google-Smtp-Source: AGRyM1vfAz4nYaYXojroBzq5KWiZRFn5bk/JU96hitxFveZR7fyQu+0CEcHEugmroP8FCBjpV7cdOQ0hrleKIxj6Rxo= X-Received: by 2002:a05:600c:1906:b0:39c:7f82:3090 with SMTP id j6-20020a05600c190600b0039c7f823090mr18668927wmq.152.1656319223415; Mon, 27 Jun 2022 01:40:23 -0700 (PDT) MIME-Version: 1.0 References: <20220623000530.1194226-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Mon, 27 Jun 2022 01:39:46 -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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656319224; a=rsa-sha256; cv=none; b=PsCvXUrq59aVK8cama7I+f+TBeCz71oNtiuFy9Kj5hXuI0YUnWU4gqW9N1HLkunZQaKqjx UaOpOiggLNWj7tbQOS3dZds1KeFewl4G1Mkxl/u4qVYb2QqhwASJduHi2yQjJKY+pkzkWa evge5PyzjLK+X3gDFuzBWCrpKB+KG2U= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Wuf9RiWG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.43 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=1656319224; 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=XRmJjWWFtnuNSlD/e9eL++RxDIH2gU2v0iOznKKFYn8=; b=OJBCBSHZxbP2RnpzGyPjLwpLvqsc9QOH3/DsN3kLeCMfBhJ8kIxQ5YouIxvWlkwfmtJA54 +m6DuVNjcCyTWNzoaUnxjxlVk30qvw8Wbdt+nFQVUKOAaypz09M2UXgJidXH3E+5O/F7AV HjqGQt13V6q2dNwxcqINHHkKQKN8+b4= X-Rspam-User: X-Stat-Signature: qgqb45oc1fjndni7u1ky157i7hutt7mq X-Rspamd-Queue-Id: DDEC14002A Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Wuf9RiWG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspamd-Server: rspam03 X-HE-Tag: 1656319224-319944 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 1:25 AM Michal Hocko wrote: > > On Thu 23-06-22 10:26:11, Yosry Ahmed wrote: > > On Thu, Jun 23, 2022 at 10:04 AM Michal Hocko wrote: > > > > > > On Thu 23-06-22 09:42:43, Shakeel Butt wrote: > > > > On Thu, Jun 23, 2022 at 9:37 AM Michal Hocko wrote: > > > > > > > > > > On Thu 23-06-22 09:22:35, Yosry Ahmed wrote: > > > > > > On Thu, Jun 23, 2022 at 2:43 AM Michal Hocko wrote: > > > > > > > > > > > > > > On Thu 23-06-22 01:35:59, Yosry Ahmed wrote: > > > > > [...] > > > > > > > > In our internal version of memory.reclaim that we recently upstreamed, > > > > > > > > we do not account vmpressure during proactive reclaim (similar to how > > > > > > > > psi is handled upstream). We want to make sure this behavior also > > > > > > > > exists in the upstream version so that consolidating them does not > > > > > > > > break our users who rely on vmpressure and will start seeing increased > > > > > > > > pressure due to proactive reclaim. > > > > > > > > > > > > > > These are good reasons to have this patch in your tree. But why is this > > > > > > > patch benefitial for the upstream kernel? It clearly adds some code and > > > > > > > some special casing which will add a maintenance overhead. > > > > > > > > > > > > It is not just Google, any existing vmpressure users will start seeing > > > > > > false pressure notifications with memory.reclaim. The main goal of the > > > > > > patch is to make sure memory.reclaim does not break pre-existing users > > > > > > of vmpressure, and doing it in a way that is consistent with psi makes > > > > > > sense. > > > > > > > > > > memory.reclaim is v2 only feature which doesn't have vmpressure > > > > > interface. So I do not see how pre-existing users of the upstream kernel > > > > > can see any breakage. > > > > > > > > > > > > > Please note that vmpressure is still being used in v2 by the > > > > networking layer (see mem_cgroup_under_socket_pressure()) for > > > > detecting memory pressure. > > > > > > I have missed this. It is hidden quite good. I thought that v2 is > > > completely vmpressure free. I have to admit that the effect of > > > mem_cgroup_under_socket_pressure is not really clear to me. Not to > > > mention whether it should or shouldn't be triggered for the user > > > triggered memory reclaim. So this would really need some explanation. > > > > vmpressure was tied into socket pressure by 8e8ae645249b ("mm: > > memcontrol: hook up vmpressure to socket pressure"). A quick look at > > the commit log and the code suggests that this is used all over the > > socket and tcp code to throttles the memory consumption of the > > networking layer if we are under pressure. > > > > However, for proactive reclaim like memory.reclaim, the target is to > > probe the memcg for cold memory. Reclaiming such memory should not > > have a visible effect on the workload performance. I don't think that > > any network throttling side effects are correct here. > > Please describe the user visible effects of this change. IIUC this is > changing the vmpressure semantic for pre-existing users (v1 when setting > the hard limit for example) and it really should be explained why > this is good for them after those years. I do not see any actual bug > being described explicitly so please make sure this is all properly > documented. In cgroup v1, user-induced reclaim that is caused by limit-setting (or memory.reclaim for systems that choose to expose it in cgroup v1) will no longer cause vmpressure notifications, which makes the vmpressure behavior consistent with the current psi behavior. In cgroup v2, user-induced reclaim (limit-setting, memory.reclaim, ..) would currently cause the networking layer to perceive the memcg as being under memory pressure, reducing memory consumption and possibly causing throttling. This patch makes the networking layer only perceive the memcg as being under pressure when the "pressure" is caused by increased memory usage, not limit-setting or proactive reclaim, which also makes the definition of memcg memory pressure consistent with psi today. In short, the purpose of this patch is to unify the definition of memcg memory pressure across psi and vmpressure (which indirectly also defines the definition of memcg memory pressure for the networking layer). If this sounds good to you, I can add this explanation to the commit log, and possibly anywhere you see appropriate in the code/docs. > > -- > Michal Hocko > SUSE Labs