Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp77131imm; Thu, 2 Aug 2018 23:17:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcCWmBebeCD+WdNurZQ9YaIrvxfE461iiStz0733lAJZui9HeI+69IkVD8lRvdbTmX0hZWg X-Received: by 2002:a63:6743:: with SMTP id b64-v6mr2324239pgc.91.1533277033242; Thu, 02 Aug 2018 23:17:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533277033; cv=none; d=google.com; s=arc-20160816; b=T+h3sAipU37zKQYShbCyUggFMSMx82Q0rddq2r/K09FNUTz3TTh/DSqPb0+sI8X+2u bNaWqT1Qn0pZmy0AteUhrS4HPfZYQjMZLivGsZ9MNZPp6gHu1wFDKW3K1SMJ/cgi9x8M 6X3TaThn40SSjDhw3yyIPfF7wcaRuk230aSBJ6c/tbWjrqJAGbVkIzPjt1R1795SFg3n c79fPsqUs26zSDsI2qqjihv/r3gpUHecrRKmS+3lEwuVWSBA5ChVZbdYJ3Gx+ai8lZ7V 5YG6bvYMuiRiGeZHmmrvcNeicrSJpehhKhNIrpBqgsPyRRWDfMm+P5CwbALsOjCHdhBx yNOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Z5YghRSzisyGo1MsqZmUMQslTHqAzzKmj7Sk0UoXwaI=; b=M8ENbMqLNy2sI5UsDG7hvYIzETcld8eyr4XTl9Oz3I43kPvs3OckzW5EvGrn/DgrvV MntzZV4eXXyBFhhYDDKpqJpJ6dYESSQpjEhoCMlKDw7mBgoI3aEeqkIOfwEQCy9iy28P OZrTxVZHaZYkFk0DLAwfAEqEfUBhDOHslOfyH4UxRkT1S4hEhcjv5xvRiTxCBaVxP88d o39xIcqQRZVgyFqe014ulMDxb63C+VRJvsPWY+96gTl1KF3lavH+cKItavVh2VuEfZyw XPANJTSqWb9RGHvC92pF0MA4q75Jq+cFgLle7ekMAxcqXNBNfuVhpyzfNIhQQaD2jaa5 n62Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e125-v6si3959167pgc.424.2018.08.02.23.16.58; Thu, 02 Aug 2018 23:17:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729790AbeHCIKM (ORCPT + 99 others); Fri, 3 Aug 2018 04:10:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:52836 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729601AbeHCIKM (ORCPT ); Fri, 3 Aug 2018 04:10:12 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6BB58ADF7; Fri, 3 Aug 2018 06:15:28 +0000 (UTC) Date: Fri, 3 Aug 2018 08:15:27 +0200 From: Michal Hocko To: Zhaoyang Huang Cc: Steven Rostedt , Ingo Molnar , Johannes Weiner , Vladimir Davydov , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-patch-test@lists.linaro.org Subject: Re: [PATCH v1] mm:memcg: skip memcg of current in mem_cgroup_soft_limit_reclaim Message-ID: <20180803061527.GA27245@dhcp22.suse.cz> References: <1533275285-12387-1-git-send-email-zhaoyang.huang@spreadtrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1533275285-12387-1-git-send-email-zhaoyang.huang@spreadtrum.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 03-08-18 13:48:05, Zhaoyang Huang wrote: > for the soft_limit reclaim has more directivity than global reclaim, we > have current memcg be skipped to avoid potential page thrashing. a) this changelog doesn't really explain the problem nor does it explain why the proposed solution is reasonable or why it works at all and b) no, this doesn't really work. You could easily break the current soft limit semantic. I understand that you are not really happy about how the soft limit works. Me neither but this whole interface is a huge mistake of past and the general recommendation is to not use it. We simply cannot fix it because it is unfixable. The semantic is just broken and somebody might really depend on it. > Signed-off-by: Zhaoyang Huang > --- > mm/memcontrol.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 8c0280b..9d09e95 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2537,12 +2537,21 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order, > mz = mem_cgroup_largest_soft_limit_node(mctz); > if (!mz) > break; > - > + /* > + * skip current memcg to avoid page thrashing, for the > + * mem_cgroup_soft_reclaim has more directivity than > + * global reclaim. > + */ > + if (get_mem_cgroup_from_mm(current->mm) == mz->memcg) { > + reclaimed = 0; > + goto next; > + } > nr_scanned = 0; > reclaimed = mem_cgroup_soft_reclaim(mz->memcg, pgdat, > gfp_mask, &nr_scanned); > nr_reclaimed += reclaimed; > *total_scanned += nr_scanned; > +next: > spin_lock_irq(&mctz->lock); > __mem_cgroup_remove_exceeded(mz, mctz); > > -- > 1.9.1 -- Michal Hocko SUSE Labs