Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2912311iog; Mon, 27 Jun 2022 05:37:33 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tl/6GzFaouco7iiBxfJXttDA3wBMvUxuIF5Fq9hoE1oeKKzVemhcWDhDijxKibTRQyBqyv X-Received: by 2002:a17:906:8501:b0:711:bf65:2a47 with SMTP id i1-20020a170906850100b00711bf652a47mr12873913ejx.150.1656333453640; Mon, 27 Jun 2022 05:37:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656333453; cv=none; d=google.com; s=arc-20160816; b=rkk9curm6rvZji1tzapd0ankqkUaO7W1+rMp6sMxpc323WH21pzZCr+9lkoJfm1t9x mNF6Sq3AhO9o+FjfwT+Uzc+qtWUpl7LEqM5GYo8HBt1FIvjcQqg66owv22q/N6sckeUq 21XVkKIACnOFRVruvZzObPYxqLGrHQTls5qMkf3WkqpUSHu5R4uq33ILl0MXTw+A5DkN iYIRRGBQ35LdshZU/jhRCtnuHJ+aW8pj8sed4k/IP3b+E7A1spBasE+0XItlHwTp5xnO X6pdOVVG8t2EkXgv+I2NMBE3cihKlQzbSoqOyByG9Y5SKUoY9EPby+HOswFfiMWKh4uC nbkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=H2x18KoFRy5eal2D3ylc2+U1rybp7813ga/wOUoNe6s=; b=ukP4e0JRWkqf3IqZkmv/ehw7yKFMIOrn2mSEwP5YPd5v0qN+ZFpXGd814XQwb70Jb7 EmH2kkE1L33qAPC9Iujr7ysq3Gcue16CbRN7n9DrRMbcMqU1bxL2/qKGiIDZ1VOcz9oG 8JuGmO+eiuNoNA6HiEKVMDvd91priZvXcZYS6ZyUf4QN1Pml13hfBjcEJiE4K4J0TA1X ML5g9ugz5VzJ9eVV/EoirsUyBTWnM2ZRa4OuFQBv7oa0YwWAZ1SLeAKQ5fYhILnP2nST um+iVsfIhHmjtUmsAda4+Z4ioLw4vRQO4lyo66zKjqsdWWXy4itl4pu/uxtVFGwOb6l7 exDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=MN+FbeFB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji8-20020a170907980800b0070f416ab5cdsi13884039ejc.110.2022.06.27.05.37.07; Mon, 27 Jun 2022 05:37:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=MN+FbeFB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234273AbiF0Mbo (ORCPT + 99 others); Mon, 27 Jun 2022 08:31:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235685AbiF0Mba (ORCPT ); Mon, 27 Jun 2022 08:31:30 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79922DED1; Mon, 27 Jun 2022 05:31:29 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 23B0F21CE4; Mon, 27 Jun 2022 12:31:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1656333088; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H2x18KoFRy5eal2D3ylc2+U1rybp7813ga/wOUoNe6s=; b=MN+FbeFBztRg1vQn/aZS6WgzpJcvWE6GlhrAy1Bn2uYz6Fgk3nG1G2IBxSamszzE041LHN FYiV/4Oov7dyHxK7Ap2HTWMY4KowzOrjMf2zZGO5NgGZfnmfaD9ie3tBC7hiO/8eBkBjto EEejyW10KiaUFmPLEkSEZ9i8fEwxLpw= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 87FAA2C141; Mon, 27 Jun 2022 12:31:27 +0000 (UTC) Date: Mon, 27 Jun 2022 14:31:27 +0200 From: Michal Hocko To: Yosry Ahmed 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 Subject: Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as memory pressure Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > (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? -- Michal Hocko SUSE Labs