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 0D164C433EF for ; Thu, 10 Mar 2022 08:54:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79FE68D0002; Thu, 10 Mar 2022 03:54:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 751418D0001; Thu, 10 Mar 2022 03:54:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63E0B8D0002; Thu, 10 Mar 2022 03:54:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 526428D0001 for ; Thu, 10 Mar 2022 03:54:03 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0653D180E74E1 for ; Thu, 10 Mar 2022 08:54:03 +0000 (UTC) X-FDA: 79227864366.22.4BC04FA Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf21.hostedemail.com (Postfix) with ESMTP id 6F9811C001A for ; Thu, 10 Mar 2022 08:54:02 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 3CEDE1F381; Thu, 10 Mar 2022 08:54:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1646902441; 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=bB4O0HFf3zvgJcW3Y2L9rgnwJyEhjx/ntH/JW+sY980=; b=eDKdavwIJn6UYpw1ar2leRFjV+vHAIb4jBDc71F1xDlxTmIVxbJo+0JohdSWIYcvUqx8Pn up/o1qJDlZClUxrza1JKTjahrfhp5OMLN35sIWcHGRubsBvN0qKeJaJtZhqtOOG6Hgwr13 uIg+SgiUY1xoUclY93/SX+M4ukzuRQ8= 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 73CB2A3B98; Thu, 10 Mar 2022 08:54:00 +0000 (UTC) Date: Thu, 10 Mar 2022 09:53:59 +0100 From: Michal Hocko To: Wei Yang Cc: hannes@cmpxchg.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Tim Chen Subject: Re: [PATCH 3/3] mm/memcg: add next_mz back if not reclaimed yet Message-ID: References: <20220308012047.26638-1-richard.weiyang@gmail.com> <20220308012047.26638-3-richard.weiyang@gmail.com> <20220309004620.fgotfh4wsquscbfn@master> <20220310011350.2b6fxa66it5nugcy@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220310011350.2b6fxa66it5nugcy@master> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6F9811C001A X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=eDKdavwI; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Stat-Signature: 7thbkgo5gor4ruh7es3mdc8kgmtwi9ko X-HE-Tag: 1646902442-981735 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 10-03-22 01:13:50, Wei Yang wrote: > On Wed, Mar 09, 2022 at 02:48:45PM +0100, Michal Hocko wrote: > >[Cc Tim - the patch is http://lkml.kernel.org/r/20220308012047.26638-3-richard.weiyang@gmail.com] > > > >On Wed 09-03-22 00:46:20, Wei Yang wrote: > >> On Tue, Mar 08, 2022 at 09:17:58AM +0100, Michal Hocko wrote: > >> >On Tue 08-03-22 01:20:47, Wei Yang wrote: > >> >> next_mz is removed from rb_tree, let's add it back if no reclaim has > >> >> been tried. > >> > > >> >Could you elaborate more why we need/want this? > >> > > >> > >> Per my understanding, we add back the right most node even reclaim makes no > >> progress, so it is reasonable to add back a node if we didn't get a chance to > >> do reclaim on it. > > > >Your patch sounded familiar and I can remember now. The same fix has > >been posted by Tim last year > >https://lore.kernel.org/linux-mm/8d35206601ccf0e1fe021d24405b2a0c2f4e052f.1613584277.git.tim.c.chen@linux.intel.com/ > >It was posted with other changes to the soft limit code which I didn't > >like but I have acked this particular one. Not sure what has happened > >with it afterwards. > > Because of this ? > 4f09feb8bf: vm-scalability.throughput -4.3% regression > https://lore.kernel.org/linux-mm/20210302062521.GB23892@xsang-OptiPlex-9020/ That was a regression for a different patch in the series AFAICS: : FYI, we noticed a -4.3% regression of vm-scalability.throughput due to commit: : : commit: 4f09feb8bf083be3834080ddf3782aee12a7c3f7 ("mm: Force update of mem cgroup soft limit tree on usage excess") That patch has played with how often memcg_check_events is called and that can lead to a visible performance difference. -- Michal Hocko SUSE Labs