Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754208Ab0KSND6 (ORCPT ); Fri, 19 Nov 2010 08:03:58 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:57894 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with SMTP id S1754101Ab0KSND5 (ORCPT ); Fri, 19 Nov 2010 08:03:57 -0500 X-Authenticated: #14349625 X-Provags-ID: V01U2FsdGVkX1+5KB56Frm5QDcbw0vs/HddwI/ZbyMHN2OK9iE0xR YzdUo15Vao7wx3 Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups From: Mike Galbraith To: Peter Zijlstra Cc: Paul Menage , Samuel Thibault , Hans-Peter Jansen , linux-kernel@vger.kernel.org, Lennart Poettering , Linus Torvalds , david@lang.hm, Dhaval Giani , Vivek Goyal , Oleg Nesterov , Markus Trippelsdorf , Mathieu Desnoyers , Ingo Molnar , Balbir Singh In-Reply-To: <1290171113.2109.1574.camel@laptop> References: <1289916171.5169.117.camel@maggy.simson.net> <20101116211431.GA15211@tango.0pointer.de> <201011182333.48281.hpj@urpla.net> <20101118231218.GX6024@const.famille.thibault.fr> <1290123351.18039.49.camel@maggy.simson.net> <20101118234339.GA6024@const.famille.thibault.fr> <1290167376.2109.1553.camel@laptop> <1290171113.2109.1574.camel@laptop> Content-Type: text/plain; charset="UTF-8" Date: Fri, 19 Nov 2010 06:03:34 -0700 Message-ID: <1290171814.3840.52.camel@maggy.simson.net> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1092 Lines: 25 On Fri, 2010-11-19 at 13:51 +0100, Peter Zijlstra wrote: > On Fri, 2010-11-19 at 04:31 -0800, Paul Menage wrote: > > On Fri, Nov 19, 2010 at 3:49 AM, Peter Zijlstra wrote: > > > It must be nice to be that ignorant ;-) Speaking for the scheduler > > > cgroup controller (that being the only one I actually know), most all > > > the load-balance operations are O(n) in the number of active cgroups, > > > and a lot of the cpu local schedule operations are O(d) where d is the > > > depth of the cgroup tree. > > > > The same would apply to CPU autogroups, presumably? > > Yep, they're not special at all... uses the same mechanism. The only difference is cost of creation and destruction, so cgroups and autogroups suck boulders of slightly different diameter when creating and/or destroying at high frequency. -Mike -- 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/