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 F2358C433EF for ; Thu, 30 Jun 2022 08:22:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 728426B0072; Thu, 30 Jun 2022 04:22:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D78F8E0001; Thu, 30 Jun 2022 04:22:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EDB56B0074; Thu, 30 Jun 2022 04:22:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 50B8E6B0072 for ; Thu, 30 Jun 2022 04:22:23 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A2EEB34796 for ; Thu, 30 Jun 2022 08:22:22 +0000 (UTC) X-FDA: 79634210124.07.01CAA0B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf22.hostedemail.com (Postfix) with ESMTP id 015ADC0038 for ; Thu, 30 Jun 2022 08:22:21 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id A57CD21CA3; Thu, 30 Jun 2022 08:22:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1656577340; 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=VazjpIcq3Rp1eYxn5z7a3G7XqRklXOW4+Iv+aLJycac=; b=Z4q7b7Tv2K4y6bML5JDMKNXAp/3cMhrw1YjTHkivEtZmt0HRHEcPn1LT7wVU5jJ+CuX9AX ZGMpT+XS8r5g90JtJgzl+AR29D1omYEZ+O9qayyZTh/y+Ubo1diTU+Y6QJjnphzSqTeo1E Fc1wPLLAl5HxlD1w1Y1Anr89gy5iC/E= 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 CF5A32C141; Thu, 30 Jun 2022 08:22:19 +0000 (UTC) Date: Thu, 30 Jun 2022 10:22:19 +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: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656577342; a=rsa-sha256; cv=none; b=8Ap6ePTAx7A/zVASu1vE8+NjBPlGwLWReO59vl1qgosp0m3TdqZH8ACA+brePuaj2QpgET H2xLapMXiZJjnr1fpdAubXZW0nKlqdVCK5xvXoHy7VR9dUW7I7Na1m6lk+VwOghPxdIg12 JdvXcLWQ/aPmxkVvG8cuMrbqxIOWADs= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Z4q7b7Tv; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656577342; 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=VazjpIcq3Rp1eYxn5z7a3G7XqRklXOW4+Iv+aLJycac=; b=g5kSi22pNfN4kaXcabAQA7bzbmIlH7usi+Q9TzG6veKOOqZ9n2RQQQ19EKnP6SXdPYjPZ/ BKfM/IBjmIrvUIZn+acoEmorMAKh//9mzBQOQu4MobZxn33K/zwVr7tfwfN2RhBEAtScm0 jlxt0eiYTZY5wbjmnL9eJ+Jc4Gym6Jc= Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Z4q7b7Tv; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 015ADC0038 X-Stat-Signature: b1mei8e8oc9i9tu9nto1mn5bcy3dre73 X-Rspam-User: X-HE-Tag: 1656577341-933068 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 Wed 29-06-22 19:08:42, Yosry Ahmed wrote: > On Wed, Jun 29, 2022 at 6:07 PM Shakeel Butt wrote: > > > > 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. > > So it seems like we should only ignore vmpressure for proactive > reclaim (aka memory.reclaim). > > Michal, let me know what you think here, I can drop psi and > limit-setting changes in v3 and basically just ignore vmpressure for > memory.reclaim (MEMCG_RECLAIM_PROACTIVE / sc->proactive instead of > MEMCG_RECLAIM_CONTROLLED / sc->controlled maybe). Yes, that makes much more sense to me. -- Michal Hocko SUSE Labs