Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760901Ab0KRXoP (ORCPT ); Thu, 18 Nov 2010 18:44:15 -0500 Received: from solo.fdn.fr ([80.67.169.19]:54999 "EHLO solo.fdn.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755787Ab0KRXoN (ORCPT ); Thu, 18 Nov 2010 18:44:13 -0500 Date: Fri, 19 Nov 2010 00:43:39 +0100 From: Samuel Thibault To: Mike Galbraith Cc: Hans-Peter Jansen , linux-kernel@vger.kernel.org, Lennart Poettering , Linus Torvalds , david@lang.hm, Dhaval Giani , Peter Zijlstra , Vivek Goyal , Oleg Nesterov , Markus Trippelsdorf , Mathieu Desnoyers , Ingo Molnar , Balbir Singh Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups Message-ID: <20101118234339.GA6024@const.famille.thibault.fr> Mail-Followup-To: Samuel Thibault , Mike Galbraith , Hans-Peter Jansen , linux-kernel@vger.kernel.org, Lennart Poettering , Linus Torvalds , david@lang.hm, Dhaval Giani , Peter Zijlstra , Vivek Goyal , Oleg Nesterov , Markus Trippelsdorf , Mathieu Desnoyers , Ingo Molnar , Balbir Singh 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1290123351.18039.49.camel@maggy.simson.net> User-Agent: Mutt/1.5.12-2006-07-14 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1303 Lines: 26 Mike Galbraith, le Thu 18 Nov 2010 16:35:51 -0700, a ?crit : > On Fri, 2010-11-19 at 00:12 +0100, Samuel Thibault wrote: > > Hans-Peter Jansen, le Thu 18 Nov 2010 23:33:46 +0100, a ?crit : > > > As already mentioned countless times (and some of it was even renamed > > > for this very fact): the grouping by tty is just a starter. There are > > > plenty of other possibilities to group the scheduling. The hard part is > > > to find the right grouping concepts, that are making sense in the > > > usability department _and_ are easy enough to be picked up from our > > > favorite system and desktop environments. That's where the generic > > > cgroup concept seems to be lacking ATM.. > > > > Actually, cgroups should probably be completely hierarchical: sessions > > contain process groups, which contain processes, which contain threads. > > You could also gather sessions with the same uid. > > Hierarchical is ~tempting, but adds overhead for not much gain. What overhead? The implementation of cgroups is actually already hierarchical. Samuel -- 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/