Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753521AbbG2Qhr (ORCPT ); Wed, 29 Jul 2015 12:37:47 -0400 Received: from relay.parallels.com ([195.214.232.42]:39813 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752025AbbG2Qhn (ORCPT ); Wed, 29 Jul 2015 12:37:43 -0400 Date: Wed, 29 Jul 2015 19:37:26 +0300 From: Vladimir Davydov To: Andres Lagar-Cavilla CC: Michal Hocko , Andrew Morton , Minchan Kim , "Raghavendra K T" , Johannes Weiner , Greg Thelen , Michel Lespinasse , David Rientjes , Pavel Emelyanov , Cyrill Gorcunov , Jonathan Corbet , , , , , Subject: Re: [PATCH -mm v9 0/8] idle memory tracking Message-ID: <20150729163725.GZ8100@esperanza> References: <20150729123629.GI15801@dhcp22.suse.cz> <20150729135907.GT8100@esperanza> <20150729142618.GJ15801@dhcp22.suse.cz> <20150729152817.GV8100@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: US-EXCH.sw.swsoft.com (10.255.249.47) To US-EXCH2.sw.swsoft.com (10.255.249.46) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2308 Lines: 60 On Wed, Jul 29, 2015 at 08:55:01AM -0700, Andres Lagar-Cavilla wrote: > On Wed, Jul 29, 2015 at 8:28 AM, Vladimir Davydov > wrote: > > On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote: > >> On Wed 29-07-15 16:59:07, Vladimir Davydov wrote: > >> > On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote: > >> > > On Sun 19-07-15 15:31:09, Vladimir Davydov wrote: > >> > > [...] > >> > > > ---- USER API ---- > >> > > > > >> > > > The user API consists of two new proc files: > >> > > > >> > > I was thinking about this for a while. I dislike the interface. It is > >> > > quite awkward to use - e.g. you have to read the full memory to check a > >> > > single memcg idleness. This might turn out being a problem especially on > >> > > large machines. > >> > > >> > Yes, with this API estimating the wss of a single memory cgroup will > >> > cost almost as much as doing this for the whole system. > >> > > >> > Come to think of it, does anyone really need to estimate idleness of one > >> > particular cgroup? > > You can always adorn memcg with a boolean, trivially configurable from > user-space, and have all the idle computation paths skip the code if > memcg->dont_care_about_idle Or we can filter out cgroups in which we're not interested using /proc/kpagecgroup. > > >> > >> It is certainly interesting for setting the low limit. > > > > Valuable, IMHO > > > Yes, but IMO there is no point in setting the low limit for one > > particular cgroup w/o considering what's going on with the rest of the > > system. > > > > Probably worth more fleshing out. Why not? Because global reclaim can > execute in any given context, so a noisy neighbor hurts all? The low limit does not necessarily mean, the cgroup will never get pushed below it. It will, if others feel really bad. Also, by setting the low limit too high, you can make others thrash constantly, which will increase IO, which, in turn, might hurt the workload you're trying to protect. Blkio cgroup might help in this case though. Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/