Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752334Ab2KSN5s (ORCPT ); Mon, 19 Nov 2012 08:57:48 -0500 Received: from mx2.parallels.com ([64.131.90.16]:46761 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634Ab2KSN5r (ORCPT ); Mon, 19 Nov 2012 08:57:47 -0500 Message-ID: <50AA3ABF.4090803@parallels.com> Date: Mon, 19 Nov 2012 17:57:19 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: David Rientjes CC: Anton Vorontsov , "Kirill A. Shutemov" , Pekka Enberg , Mel Gorman , Leonid Moiseichuk , "KOSAKI Motohiro" , Minchan Kim , Bartlomiej Zolnierkiewicz , John Stultz , , , , , , , KAMEZAWA Hiroyuki , Michal Hocko , Johannes Weiner , Tejun Heo Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications References: <20121107105348.GA25549@lizard> <20121107112136.GA31715@shutemov.name> <20121107114321.GA32265@shutemov.name> <20121115033932.GA15546@lizard.sbx05977.paloaca.wayport.net> <20121115073420.GA19036@lizard.sbx05977.paloaca.wayport.net> <20121115085224.GA4635@lizard> <50A60873.3000607@parallels.com> <50A6AC48.6080102@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2507 Lines: 57 On 11/17/2012 01:57 AM, David Rientjes wrote: > On Sat, 17 Nov 2012, Glauber Costa wrote: > >>> I'm wondering if we should have more than three different levels. >>> >> >> 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. >>> Umm, why do users of cpusets not want to be able to trigger memory >>> pressure notifications? >>> >> Because cpusets only deal with memory placement, not memory usage. > > The set of nodes that a thread is allowed to allocate from may face memory > pressure up to and including oom while the rest of the system may have a > ton of free memory. Your solution is to compile and mount memcg if you > want notifications of memory pressure on those nodes. Others in this > thread have already said they don't want to rely on memcg for any of this > and, as Anton showed, this can be tied directly into the VM without any > help from memcg as it sits today. So why implement a simple and clean > mempressure cgroup that can be used alone or co-existing with either memcg > or cpusets? > >> And it is not that moving a task to cpuset disallows you to do any of >> this: you could, as long as the same set of tasks are mounted in a >> corresponding memcg. >> > > 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! -- 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/