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 16AD9C433EF for ; Fri, 24 Jun 2022 22:41:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6745D8E027C; Fri, 24 Jun 2022 18:41:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 623E78E0244; Fri, 24 Jun 2022 18:41:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C3C88E027C; Fri, 24 Jun 2022 18:41:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3986E8E0244 for ; Fri, 24 Jun 2022 18:41:39 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DE8FE60D1E for ; Fri, 24 Jun 2022 22:41:38 +0000 (UTC) X-FDA: 79614602676.13.C0F4AAA Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf04.hostedemail.com (Postfix) with ESMTP id 893F340002 for ; Fri, 24 Jun 2022 22:41:38 +0000 (UTC) Received: by mail-yb1-f174.google.com with SMTP id x38so6805310ybd.9 for ; Fri, 24 Jun 2022 15:41:38 -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=PB2ou5T9HchfcMcQw7R0zS+RgHm7z0GH0PzcwmCwOgA=; b=XQE4jOFcM4OBioX8gNb6neMZZtMx9ApUxsfIs+HvbW74PPckXr9kwQl3EPOlYYez6B hJlk4uLOgUGW8gdUDBG9YVqB17VvMyYEkPvFl8nRwuScUFY362IVVVdErTsLlScS3cfY ykm30jXlcihAE8MKVVS2Kq3xjw4J7+r8yi+0+KvlXisgFGvjb3ntL+P8eTwYho4AMSgC mdBMrFgW0cc8jdW0r4MWZRBhiDZHNsQ2PizaT4z9wDWW1HHhjl16Jm0swyyHkDDQrq7f j5e6kCtnNYFwpaFURhhxhidnhV9TKrtFD2f9Emuxk0b7CnGAlvswguw3CxV2lYtXDK+7 qo3g== 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=PB2ou5T9HchfcMcQw7R0zS+RgHm7z0GH0PzcwmCwOgA=; b=TmoK8AZoiH8Zh0ZYx6hYoFGJ/zSc6BGM4hEKtK/jcqnuDTu/EVNT4lsLiYooOaIM3h Hc1gMFIqfvDrGqGQg2ovBHpxuAkVAOL0D5CS6LQ+Y/R71KJJY5DUXvrNbQ8ULvEf5UZQ z/3pXL3ZF+yefHzvfhNJkIzXIctU3HzBUCF4KrNzIg6yI6nvCjn44l7EqNL6RN5Tp97Z QraPfjhNb6QwMaggCe1VGV2r6Nwp0SHrxK3qKJG5H4DRTppMB1kC1LUBUQEjn2gbn/Pv DU7aRAtBSSWhDEvu+9nlLaeMImwpAkOH7wyiyMZlcwdbxSOeMKT6wKhKCgEFRHWhU4Hy 5kKw== X-Gm-Message-State: AJIora8lfx6SHkAduf00vApfS91NE6SQhx23CgrX5yNjwOX4JuG+4fFo itWVgcBP8LR/4ljk5hkPC5MQw1x7h7txM2J575DecA== X-Google-Smtp-Source: AGRyM1suFoUyp8iP0uugs7apRhGmegOzspGU5ROEVYlnUJ87futz+tjoolWZtAcwx7H0aLXuGoC25oxOPEm00I6SOKY= X-Received: by 2002:a25:888a:0:b0:669:9661:912 with SMTP id d10-20020a25888a000000b0066996610912mr1468060ybl.348.1656110497625; Fri, 24 Jun 2022 15:41:37 -0700 (PDT) MIME-Version: 1.0 References: <20220623000530.1194226-1-yosryahmed@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 24 Jun 2022 15:41:26 -0700 Message-ID: Subject: Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as memory pressure To: Yosry Ahmed Cc: Michal Hocko , Shakeel Butt , Johannes Weiner , Roman Gushchin , Muchun Song , Andrew Morton , Matthew Wilcox , Vlastimil Babka , David Hildenbrand , Miaohe Lin , NeilBrown , Alistair Popple , 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=1656110498; a=rsa-sha256; cv=none; b=WfIiY87BCt2zdSURlYsr3YrpHtRuKYR9PurktsM1D9VZWsWfPLg4PaAaVS3oxPrd8cpKyL 0nSIDChTBwXRm9tKmWRg+kedj+h3KV76gs7d319GRabk7iEzN2+WrS38nBhquuu/WOwMuz rWPrfq6FKiirlUEnmn5c9948rBcjmgc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656110498; 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=PB2ou5T9HchfcMcQw7R0zS+RgHm7z0GH0PzcwmCwOgA=; b=B3vILasq3MrFGeugNxi/iTcNlNP5kclmtBIPat3MkFin/WeKU4WUJpHn7WWY4lXMWBMzu0 gV+ltw0wqHyxFknbJU2cCPFQmw8V8tMhWlm592RF2R+g+RWmQfrlqzuBch0C8I7yNX57WO mF80aF+jAv6Vol2BYiNliZLCCkUTCv4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XQE4jOFc; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com X-Stat-Signature: rj3hyc5fak66664nh4fht8gfiw3zg7f4 X-Rspamd-Queue-Id: 893F340002 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XQE4jOFc; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1656110498-341452 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, Jun 24, 2022 at 3:14 PM Yosry Ahmed wrote: > > On Fri, Jun 24, 2022 at 3:10 PM Suren Baghdasaryan wrote: > > > > On Thu, Jun 23, 2022 at 10:26 AM 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. > > > > IIUC, this change is fixing two mechanisms during userspace-induced > > memory pressure: > > 1. psi accounting, which I think is not controversial and makes sense to me; > > 2. vmpressure signal, which is a "kinda" obsolete interface and might > > be viewed as controversial. > > I would suggest splitting the patch into two, first to fix psi > > accounting and second to fix vmpressure signal. This way the first one > > (probably the bigger of the two) can be reviewed and accepted easily > > while debates continue on the second one. > > This change should be NOP for psi. psi was already fixed by > e22c6ed90aa9 ("mm: memcontrol: don't count limit-setting reclaim > as memory pressure") by Johannes a while ago. This patch does the same > for vmpressure, but in a different way, as the same approach of > e22c6ed90aa9 cannot be used. > > The changes you are seeing in this patch for psi are basically > reverting e22c6ed90aa9 and using the newly introduced flag that > handles vmpressure to handle psi as well, to avoid having two separate > ways to address accounting memory pressure during userspace-induced > reclaim. Ah, I see. Thanks for clarifying that. > > > > > > > > > > > > > > > Though IMO we should deprecate vmpressure altogether. > > > > > > > > Yes it should be really limited to v1. But as I've said the effect on > > > > mem_cgroup_under_socket_pressure is not really clear to me. It really > > > > seems the v2 support has been introduced deliberately. > > > > > > > > -- > > > > Michal Hocko > > > > SUSE Labs