Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753512Ab2KUJ0I (ORCPT ); Wed, 21 Nov 2012 04:26:08 -0500 Received: from mx2.parallels.com ([64.131.90.16]:50206 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751937Ab2KUJ0F (ORCPT ); Wed, 21 Nov 2012 04:26:05 -0500 Message-ID: <50AC9E20.2060208@parallels.com> Date: Wed, 21 Nov 2012 13:25:52 +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: Anton Vorontsov CC: David Rientjes , "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: <20121115085224.GA4635@lizard> <50A60873.3000607@parallels.com> <50A6AC48.6080102@parallels.com> <50AA3FEF.2070100@parallels.com> <50AC9070.2030009@parallels.com> <20121121084603.GA18159@lizard> In-Reply-To: <20121121084603.GA18159@lizard> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2096 Lines: 48 On 11/21/2012 12:46 PM, Anton Vorontsov wrote: > On Wed, Nov 21, 2012 at 12:27:28PM +0400, Glauber Costa wrote: >> On 11/20/2012 10:23 PM, David Rientjes wrote: >>> Anton can correct me if I'm wrong, but I certainly don't think this is >>> where mempressure is headed: I don't think any accounting needs to be done > > Yup, I'd rather not do any accounting, at least not in bytes. It doesn't matter here, but memcg doesn't do any accounting in bytes as well. It only display it in bytes, but internally, it's all pages. The bytes representation is convenient, because then you can be agnostic of page sizes. > >>> and, if it is, it's a design issue that should be addressed now rather >>> than later. I believe notifications should occur on current's mempressure >>> cgroup depending on its level of reclaim: nobody cares if your memcg has a >>> limit of 64GB when you only have 32GB of RAM, we'll want the notification. >> >> My main concern is that to trigger those notifications, one would have >> to first determine whether or not the particular group of tasks is under >> pressure. > > As far as I understand, the notifications will be triggered by a process > that tries to allocate memory. So, effectively that would be a per-process > pressure. > > So, if one process in a group is suffering, we notify that "a process in a > group is under pressure", and the notification goes to a cgroup listener If you effectively have a per-process mechanism, why do you need an extra cgroup at all? It seems to me that this is simply something that should be inherited over fork, and then you register the notifier in your first process, and it will be valid for everybody in the process tree. If you need tasks in different processes to respond to the same notifier, then you just register the same notifier in two different processes. -- 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/