Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933324Ab2KODVT (ORCPT ); Wed, 14 Nov 2012 22:21:19 -0500 Received: from mail-pb0-f46.google.com ([209.85.160.46]:36648 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933227Ab2KODVR (ORCPT ); Wed, 14 Nov 2012 22:21:17 -0500 Date: Wed, 14 Nov 2012 19:21:14 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: "Kirill A. Shutemov" cc: Pekka Enberg , Anton Vorontsov , Mel Gorman , Leonid Moiseichuk , KOSAKI Motohiro , Minchan Kim , Bartlomiej Zolnierkiewicz , John Stultz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org, patches@linaro.org, kernel-team@android.com, linux-man@vger.kernel.org Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications In-Reply-To: <20121107114321.GA32265@shutemov.name> Message-ID: References: <20121107105348.GA25549@lizard> <20121107112136.GA31715@shutemov.name> <20121107114321.GA32265@shutemov.name> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1817 Lines: 37 On Wed, 7 Nov 2012, Kirill A. Shutemov wrote: > > > Sorry, I didn't follow previous discussion on this, but could you > > > explain what's wrong with memory notifications from memcg? > > > As I can see you can get pretty similar functionality using memory > > > thresholds on the root cgroup. What's the point? > > > > Why should you be required to use cgroups to get VM pressure events to > > userspace? > > Valid point. But in fact you have it on most systems anyway. > > I personally don't like to have a syscall per small feature. > Isn't it better to have a file-based interface which can be used with > normal file syscalls: open()/read()/poll()? > I agree that eventfd is the way to go, but I'll also add that this feature seems to be implemented at a far too coarse of level. Memory, and hence memory pressure, is constrained by several factors other than just the amount of physical RAM which vmpressure_fd is addressing. What about memory pressure caused by cpusets or mempolicies? (Memcg has its own reclaim logic and its own memory thresholds implemented on top of eventfd that people already use.) These both cause high levels of reclaim within the page allocator whereas there may be an abundance of free memory available on the system. I don't think we want several implementations of memory pressure notifications, so a more generic and flexible interface is going to be needed and I think it can't be done in an extendable way through this vmpressure_fd syscall. Unfortunately, I think that means polling on a per-thread notifier. -- 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/