Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752690Ab2KSOTp (ORCPT ); Mon, 19 Nov 2012 09:19:45 -0500 Received: from mx2.parallels.com ([64.131.90.16]:47689 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752334Ab2KSOTo (ORCPT ); Mon, 19 Nov 2012 09:19:44 -0500 Message-ID: <50AA3FEF.2070100@parallels.com> Date: Mon, 19 Nov 2012 18:19:27 +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: 1975 Lines: 41 >>> 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? > Forgot this one: Because there is a huge ongoing work going on by Tejun aiming at reducing the effects of orthogonal hierarchy. There are many controllers today that are "close enough" to each other (cpu, cpuacct; net_prio, net_cls), and in practice, it brought more problems than it solved. So yes, *maybe* mempressure is the answer, but it need to be justified with care. Long term, I think a saner notification API for memcg will lead us to a better and brighter future. There is also yet another aspect: This scheme works well for global notifications. If we would always want this to be global, this would work neatly. But as already mentioned in this thread, at some point we'll want this to work for a group of processes as well. At that point, you'll have to count how much memory is being used, so you can determine whether or not pressure is going on. You will, then, have to redo all the work memcg already does. -- 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/