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 17191C43334 for ; Thu, 30 Jun 2022 01:07:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 884046B0072; Wed, 29 Jun 2022 21:07:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 834838E0002; Wed, 29 Jun 2022 21:07:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FAB18E0001; Wed, 29 Jun 2022 21:07:13 -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 5CE0E6B0072 for ; Wed, 29 Jun 2022 21:07:13 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2D7EC35290 for ; Thu, 30 Jun 2022 01:07:13 +0000 (UTC) X-FDA: 79633113546.20.67D2C22 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf11.hostedemail.com (Postfix) with ESMTP id D18D940043 for ; Thu, 30 Jun 2022 01:07:12 +0000 (UTC) Received: by mail-pf1-f178.google.com with SMTP id x4so16682503pfq.2 for ; Wed, 29 Jun 2022 18:07:12 -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=b24zTk0e6let+DmkyD3O6bwmQoOkoTYKCmgGUtQJ0ic=; b=q0wyUYDG3+RW5ZLzjV35nCB9Kyy1ozJ2yhLjTJx+jH+RFiJMIeE/Mtb/vTnUBCJ5Ih uAk1TObOeVDjM4rMjngdp//PkZ3aaqMSuuV5u+clo8zOT2ad+zUv7Vc3Jxclt7ya6cBV 6aVVoL4/4XC9uS9ZO8wNheVKyaK0aZdXBw98tU2bw0u1C1G0HG8GkWMuNQRnrapiT7DF hSgxjq9XzbluDoYOQjrZ5RyCsgJ4lTnxn9SDIeoAf/NKvlXgYBqR8IIEPMbFWdduQ0ZF nmKXYcL7awq84bzQ6SoG2zTHSNcdCXlzSgRly8d4lnWuoQFc7oI7/YkEhSFVU48n7iqX 2PnQ== 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=b24zTk0e6let+DmkyD3O6bwmQoOkoTYKCmgGUtQJ0ic=; b=1j7TKAhD+1ESUFSWrOSv2ClNBzihhsJqTTvGemc5cQT8qZamQeaEQjjdSwYFvMVTTo P27G2Ud69kJI9WaowPDq5bvAo1h4ND8DJpo4AYLa+e0e9oPpaWEMERUTZ4LW+QzoUbW7 UiEtN/uGzncIjs3QMTBLlKxoDglOsE0ENUU0kBJEh0pq7RGhH2wWTvAmWLV3TmLhryMs ZKMDB5z1HgSJJkT511vd5PuYB+r4Mqtgi7mRvc4sHvznxAcaK548H1meb61YQwuiT41z kggyG+mHO/ds45OAW9f/ZJMs4Ymh4ie5OA1r3Zi9zFbJn5sd60oBCHc2cFOmgya1tZmr THzQ== X-Gm-Message-State: AJIora+7yihzqF0lWuPibgWY/9uPEeHxknfL0NPbomen8wi52MuJsIys nxGNrurqFKOM6zGiqUiO2xuuaoDcTCEC40o9IloP8g== X-Google-Smtp-Source: AGRyM1t1j0WgGjh0fBoPPJcAaXStzXPcr4K31ta8tbb+Vp/wo09weJxlO19+QLmE2GFxnGfT+NXhQwsU/MbB9V2ezsc= X-Received: by 2002:a63:711e:0:b0:40c:c08d:79e0 with SMTP id m30-20020a63711e000000b0040cc08d79e0mr5293898pgc.357.1656551231569; Wed, 29 Jun 2022 18:07:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shakeel Butt Date: Wed, 29 Jun 2022 18:07:00 -0700 Message-ID: Subject: Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as memory pressure To: Yosry Ahmed Cc: Michal Hocko , 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=1656551232; 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=b24zTk0e6let+DmkyD3O6bwmQoOkoTYKCmgGUtQJ0ic=; b=3ulvagwkv05otC79bkJUhHS6ngR5IeiqtgmZykFvRdlF81OdYByM2cOly5uijFP32FB/Q5 C28CHiXgGjHOhwxUW88l6k9/a3Y9siaLxw0kB7wrPSDzmmZTabv8tCEPM7fnFrYyLPEWPL WsVozWvjUGzvusXhEo1o3IasiL6ifDg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656551232; a=rsa-sha256; cv=none; b=DMBxGVIlXNFaAkyuEPSMPISEvU/isVIb+0+YLvN4vPpKy/2q8/78uKBd+JsCzKSy4FKJMi QHxOx3cuLLNhehOjX/gvhaJaVxj5oBKLEJ1McvTrwws1NmP/NeljWj3zT4UZ4VL2k515ZM hfdTVVAbi67erllVXWrxrzt4FJVmXxU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=q0wyUYDG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Stat-Signature: pm5tp343ccea1p7zi7zukeej654r4szn X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=q0wyUYDG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D18D940043 X-HE-Tag: 1656551232-306281 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 10:04 AM Yosry Ahmed wrote: > > On Mon, Jun 27, 2022 at 5:31 AM Michal Hocko wrote: > > [...] > > > > 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? So, the effect of returning true from mem_cgroup_under_socket_pressure() are: 1. Reducing send and receive buffers of the current socket. 2. May drop packets on the rx path. 3. May throttle current thread on the tx path. Now regarding the behavior from the reclaim due to reducing max or high, I think the kernel should not ignore vmpressure. Please note that unlike PSI which is associated with the current process, vmpressure is associated with the target memcg. So, any reclaim on that memcg due to real shortage of memory should not be ignored. That reclaim can be global reclaim or limit reclaim of ancestor or itself or reclaim due to lowering the limit of ancestor or itself.