Received: by 10.213.65.68 with SMTP id h4csp320641imn; Fri, 23 Mar 2018 05:30:08 -0700 (PDT) X-Google-Smtp-Source: AG47ELs50/JCihlRRG+UwIycvUM5ovle5inM5fvk+jvhO8pIEomB36yUH2ksIjqX8GYo5n+RFZpr X-Received: by 2002:a17:902:887:: with SMTP id 7-v6mr27691427pll.319.1521808208667; Fri, 23 Mar 2018 05:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521808208; cv=none; d=google.com; s=arc-20160816; b=jEiscO9zrG3M8x3SEk+MpiP3wqybzmvLVtSKU4nI3hrhSfn2sHRNeldRLpJDuqFWyx 59ApcVhIC4FO4PMpA0Vc5R5CQ565Q8Mtq7oyWtH6Y2mkwK3wvQc41Kllm5E+Ebk7nzcs GTDLpaVUntxHcIfXIfmXBhiuoP5idXm8XhBvZzJ378F+XlP66LxjMZgSmMqBnOKV7L6V bZqCdZCu6pz6w1lhy6qKDCgQB4LHL0uoG9LM/Jn72ZNva24XE3XH2I4h/aEr6jhi0G0N hWyIfFJSWgBFKuujPvLtBGaw+sRLyKe83HFq7PTDOJ8qeTW9SjZSSrf/v2M3wnA6fnZG 0krg== 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=JLneTBmV9aUh7NO5gi+vf7EUIHylczNlbHAvgZSQ6Kc=; b=a+3Gl2h4T1UjdX05mIb+eoRXACdZVmwVVySxcxakApuDSXZU4xQdfkEk2HwnWU8MwC iC7+PS3CEuHLmEXXUBIplE9XzUCseIO5zpmrt/2SIzrQ1f31ovPqeoEImuaeSq6Lm4qV Cnglm2oLot3Gk5xd7RJFR5SuxbDypz4hZ6ZrbAC4fbIslVsAcSLZFQIc2JBOV2CYn3Pk YCcflCPf3KM7iw+/LNpOmqV+3fZC2dt4xuFnyPYW2AWor8h0GMY8ZZ6lG8HSpvQu5Ioo oLhpovF20CWdAaN3LIeUaxd0ivOIl5RZVqCdCWM1M+GEBdN32cf7Qd039UXihxGq62Rt +iDQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v12-v6si8744019plk.615.2018.03.23.05.29.53; Fri, 23 Mar 2018 05:30:08 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752060AbeCWM3G (ORCPT + 99 others); Fri, 23 Mar 2018 08:29:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:44860 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751294AbeCWM3E (ORCPT ); Fri, 23 Mar 2018 08:29:04 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 22046AF65; Fri, 23 Mar 2018 12:29:03 +0000 (UTC) Date: Fri, 23 Mar 2018 13:29:02 +0100 From: Michal Hocko To: "Li,Rongqing" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , "hannes@cmpxchg.org" , Andrey Ryabinin Subject: Re: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlA==?= =?utf-8?B?5aSNOiBbUEFUQ0g=?= =?utf-8?Q?=5D?= mm/memcontrol.c: speed up to force empty a memory cgroup Message-ID: <20180323122902.GR23100@dhcp22.suse.cz> References: <1521448170-19482-1-git-send-email-lirongqing@baidu.com> <20180319085355.GQ23100@dhcp22.suse.cz> <2AD939572F25A448A3AE3CAEA61328C23745764B@BC-MAIL-M28.internal.baidu.com> <20180319103756.GV23100@dhcp22.suse.cz> <2AD939572F25A448A3AE3CAEA61328C2374589DC@BC-MAIL-M28.internal.baidu.com> <2AD939572F25A448A3AE3CAEA61328C2374832C1@BC-MAIL-M28.internal.baidu.com> <20180323100839.GO23100@dhcp22.suse.cz> <2AD939572F25A448A3AE3CAEA61328C2374EC73E@BC-MAIL-M28.internal.baidu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2AD939572F25A448A3AE3CAEA61328C2374EC73E@BC-MAIL-M28.internal.baidu.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 23-03-18 12:04:16, Li,Rongqing wrote: [...] > shrink_slab does not reclaim any memory, but take lots of time to > count lru > > maybe we can use the returning of shrink_slab to control if next > shrink_slab should be called? How? Different memcgs might have different amount of shrinkable memory. > Or define a slight list_lru_empty to check if sb->s_dentry_lru is > empty before calling list_lru_shrink_count, like below Does it really help to improve numbers? > diff --git a/fs/super.c b/fs/super.c > index 672538ca9831..954c22338833 100644 > --- a/fs/super.c > +++ b/fs/super.c > @@ -130,8 +130,10 @@ static unsigned long super_cache_count(struct shrinker *shrink, > if (sb->s_op && sb->s_op->nr_cached_objects) > total_objects = sb->s_op->nr_cached_objects(sb, sc); > > - total_objects += list_lru_shrink_count(&sb->s_dentry_lru, sc); > - total_objects += list_lru_shrink_count(&sb->s_inode_lru, sc); > + if (!list_lru_empty(sb->s_dentry_lru)) > + total_objects += list_lru_shrink_count(&sb->s_dentry_lru, sc); > + if (!list_lru_empty(sb->s_inode_lru)) > + total_objects += list_lru_shrink_count(&sb->s_inode_lru, sc); > > total_objects = vfs_pressure_ratio(total_objects); > return total_objects; -- Michal Hocko SUSE Labs