Message-ID: <alpine.DEB.2.00.1211200950120.4200@chino.kir.corp.google.com>
Date:	Tue, 20 Nov 2012 10:02:45 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Glauber Costa <glommer@...allels.com>
cc:	Anton Vorontsov <anton.vorontsov@...aro.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Pekka Enberg <penberg@...nel.org>,
	Mel Gorman <mgorman@...e.de>,
	Leonid Moiseichuk <leonid.moiseichuk@...ia.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Minchan Kim <minchan@...nel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	John Stultz <john.stultz@...aro.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
	patches@...aro.org, kernel-team@...roid.com,
	linux-man@...r.kernel.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Michal Hocko <mhocko@...e.cz>,
	Johannes Weiner <hannes@...xchg.org>, Tejun Heo <tj@...nel.org>
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications

On Mon, 19 Nov 2012, Glauber Costa wrote:

> >> In the case I outlined below, for backwards compatibility. What I
> >> actually mean is that memcg *currently* allows arbitrary notifications.
> >> One way to merge those, while moving to a saner 3-point notification, is
> >> to still allow the old writes and fit them in the closest bucket.
> >>
> > 
> > Yeah, but I'm wondering why three is the right answer.
> > 
> 
> This is unrelated to what I am talking about.
> I am talking about pre-defined values with a specific event meaning (in
> his patchset, 3) vs arbitrary numbers valued in bytes.
> 

Right, and I don't see how you can map the memcg thresholds onto Anton's 
scheme that heavily relies upon reclaim activity; what bucket does a 
threshold of 48MB in a memcg with a limit of 64MB fit into?  Perhaps you 
have some formula in mind that would do this, but I don't see how it works 
correctly without factoring in configuration options (memory compaction), 
type of allocation (GFP_ATOMIC won't trigger Anton's reclaim scheme like 
GFP_KERNEL), altered min_free_kbytes, etc.

This begs the question of whether the new cgroup should be considered as a 
replacement for memory thresholds within memcg in the first place; 
certainly both can coexist just fine.

> > Same thing with a separate mempressure cgroup.  The point is that there 
> > will be users of this cgroup that do not want the overhead imposed by 
> > memcg (which is why it's disabled in defconfig) and there's no direct 
> > dependency that causes it to be a part of memcg.
> > 
> I think we should shoot the duck where it is going, not where it is. A
> good interface is more important than overhead, since this overhead is
> by no means fundamental - memcg is fixable, and we would all benefit
> from it.
> 
> Now, whether or not memcg is the right interface is a different
> discussion - let's have it!
> 

I don't see memcg as being a prerequisite for any of this, I think Anton's 
cgroup can coexist with memcg thresholds, it allows for notifications in 
cpusets as well when they face memory pressure, and users need not enable 
memcg for this functionality (and memcg is pretty darn large in its memory 
footprint, I'd rather not see it fragmented either for something that can 
standalone with increased functionality).

But let's try the question in reverse: is there any specific reasons why 
this can't be implemented separately?  I sure know the cpusets + no-memcg 
configuration would benefit from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists