From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [RFD] Merge task counter into memcg Date: Wed, 11 Apr 2012 23:15:49 -0300 Message-ID: <4F863AD5.3010505@parallels.com> References: <20120411185715.GA4317@somewhere.redhat.com> <20120412010745.GE1787@cmpxchg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120412010745.GE1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Johannes Weiner Cc: "Daniel P. Berrange" , Frederic Weisbecker , Containers , Daniel Walsh , Hugh Dickins , LKML , Tejun Heo , Cgroups , Andrew Morton List-Id: containers.vger.kernel.org On 04/11/2012 10:07 PM, Johannes Weiner wrote: > You could also twist this around and argue the same for cpu usage and > make it part of the cpu cgroup, but it doesn't really fit in either > subsystem, IMO. I myself really prefer this in the cpu controller. Besides the bytes vs objects things, Whenever you create a process, at some point it will end up in the runqueues to be scheduled. It is a natural point of accounting. Either that, or making it a core feature of cgroups, like limiting the number of processes in the tasks file (just have to find a natural way to make it hierarchical). It will make more and more sense as people seem to be favoring single hierarchies these days. (granted, not a settled discussion, so your views may vary) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761745Ab2DLCRh (ORCPT ); Wed, 11 Apr 2012 22:17:37 -0400 Received: from mx2.parallels.com ([64.131.90.16]:53723 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753947Ab2DLCRf (ORCPT ); Wed, 11 Apr 2012 22:17:35 -0400 Message-ID: <4F863AD5.3010505@parallels.com> Date: Wed, 11 Apr 2012 23:15:49 -0300 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Johannes Weiner CC: Frederic Weisbecker , Hugh Dickins , Andrew Morton , KAMEZAWA Hiroyuki , Tejun Heo , Daniel Walsh , "Daniel P. Berrange" , Li Zefan , LKML , Cgroups , Containers Subject: Re: [RFD] Merge task counter into memcg References: <20120411185715.GA4317@somewhere.redhat.com> <20120412010745.GE1787@cmpxchg.org> In-Reply-To: <20120412010745.GE1787@cmpxchg.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [187.35.198.137] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/11/2012 10:07 PM, Johannes Weiner wrote: > You could also twist this around and argue the same for cpu usage and > make it part of the cpu cgroup, but it doesn't really fit in either > subsystem, IMO. I myself really prefer this in the cpu controller. Besides the bytes vs objects things, Whenever you create a process, at some point it will end up in the runqueues to be scheduled. It is a natural point of accounting. Either that, or making it a core feature of cgroups, like limiting the number of processes in the tasks file (just have to find a natural way to make it hierarchical). It will make more and more sense as people seem to be favoring single hierarchies these days. (granted, not a settled discussion, so your views may vary)