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 2EDB0C433EF for ; Thu, 23 Jun 2022 17:26:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C42838E016C; Thu, 23 Jun 2022 13:26:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF2468E0144; Thu, 23 Jun 2022 13:26:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABA058E016C; Thu, 23 Jun 2022 13:26:49 -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 9D0D98E0144 for ; Thu, 23 Jun 2022 13:26:49 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7169C607BE for ; Thu, 23 Jun 2022 17:26:49 +0000 (UTC) X-FDA: 79610180538.28.12B0E2E Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf20.hostedemail.com (Postfix) with ESMTP id 114F41C0031 for ; Thu, 23 Jun 2022 17:26:48 +0000 (UTC) Received: by mail-wr1-f44.google.com with SMTP id m1so21153487wrb.2 for ; Thu, 23 Jun 2022 10:26:48 -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=7TDx1GAcTZr/mKBq1FDoJ+WDlWvqn8HIrUeDOsFdpYQ=; b=ligNsGWDaeaYYd/G23On/R6o4SOm7zU5YC8HoZNU95O944imBcwrspvEgFwN/jGZhy BsqxtmSbvZWbeBbv+nhfMCexAkXOJe09iXp5EF8jD89itp1j+SwO0SyJqwT+axErD/Gb RLoYBG7mmML1wacS5w7d+BkAOcQFmQvKA/pXN1LSgzFGqLrJ4uawFe8Xc42ASPtIkwoj q/6hAWrCjPXdsSiMhicJLxhTYSpzYoslUad6fyTGV1PSr25ZDlw/QK7ERDUClaOKrabX 8w8zveECT9r55DBweEavza7Ov5K5Z06nVub55c0/iBZGS/2SSDgVQZKOHdoAbnjZ1yMl AZdA== 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=7TDx1GAcTZr/mKBq1FDoJ+WDlWvqn8HIrUeDOsFdpYQ=; b=gcvvz71bnN2Z85p9X7oAnO3mhoHxQrPzTRN4kX4NoYZCMPqMxLVXH45FwqWD9JRMs+ rTonX3wgYNCW3bg6kemCF7uQmxllZhUE+XKL+U0ZQ2SgIxXFQHx1tOGI72veyc1tAo25 O56hwjG6W9BYUmpfqZDBVly4I+VeTRw6YnPHyT7xTQhRmKpFRxXYQaHbalDGKidQ/3OF zOdFbFPafL2NfFVa8RjcGMAp/1zhKDlOOVs+6anSsFuKjggr+iZnTqfWUaHcUNiaIeQK 94nN6Xq+cJoDJrMm+OLLL+/u2n2MaQ3LhwP+0IIf0ICHduhj9h8HygssTNad8s12by6G DlJA== X-Gm-Message-State: AJIora/FsZeLRdxx1IAew/cEDks4ptHP0dm7WAoPNtpTaQoKXgIJYsFQ lP2q7yga9e2Nd27HA+/fFeTJOMCLXxkTVpY8gFFL+w== X-Google-Smtp-Source: AGRyM1ttFuXoFy+5+a07+hGzPPAvBJtwjefc2vBhdtGeCPnt72+WyG79pmSWHqGSSZGfFhRIy7loD1VK/eM0VISVIT4= X-Received: by 2002:a5d:4308:0:b0:219:e5a4:5729 with SMTP id h8-20020a5d4308000000b00219e5a45729mr9194972wrq.210.1656005207539; Thu, 23 Jun 2022 10:26:47 -0700 (PDT) MIME-Version: 1.0 References: <20220623000530.1194226-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 23 Jun 2022 10:26:11 -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=1656005209; a=rsa-sha256; cv=none; b=FYVe+kTq77oAQb2zY75vbDKUhQ9LAv9VSSNIoMNomNf6SlTWdBDsCNRnJUqaYlOUn3v/vd kKnHCD/DMQN1b2JcN8WVyArVhPN7RAXvzJX3MQlcGaqSXyBMBCIRxHHXKDOGs6gbm2T3UW 2EtienDFLy5FUEx2yb4L/1hO7fZrFWQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ligNsGWD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.44 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=1656005209; 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=7TDx1GAcTZr/mKBq1FDoJ+WDlWvqn8HIrUeDOsFdpYQ=; b=4lj/orSMcMlw2Qg2K8/h1bb168omGmZyHMo5s8S9E1RUg1sYOb6rF8/ACEF4Nfw56xFR2L T3hatqqGqtbypHT2YhGHv2v4PZ9eUtD4OnMKc1cUKy4L7mk1Sa9FwwVLPQvTYujLXa77p/ 1RgxHBMPAePkk0eZbcZgugGZK68sijU= X-Rspam-User: X-Stat-Signature: uo68nwidac7tbxsdabfdcdkpdbt3kzhe X-Rspamd-Queue-Id: 114F41C0031 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ligNsGWD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspamd-Server: rspam03 X-HE-Tag: 1656005208-537583 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 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. > > > 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