Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757328Ab0KPTKA (ORCPT ); Tue, 16 Nov 2010 14:10:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19515 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756706Ab0KPTJ7 (ORCPT ); Tue, 16 Nov 2010 14:09:59 -0500 Date: Tue, 16 Nov 2010 14:09:16 -0500 From: Vivek Goyal To: Peter Zijlstra Cc: david@lang.hm, Paul Menage , Lennart Poettering , Linus Torvalds , Dhaval Giani , Mike Galbraith , Oleg Nesterov , Markus Trippelsdorf , Mathieu Desnoyers , Ingo Molnar , LKML , Balbir Singh Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups Message-ID: <20101116190916.GD13092@redhat.com> References: <1289916171.5169.117.camel@maggy.simson.net> <1289916683.2109.625.camel@laptop> <20101116170312.GA19327@tango.0pointer.de> <20101116181603.GC19327@tango.0pointer.de> <1289931715.2109.648.camel@laptop> <1289933965.2109.652.camel@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1289933965.2109.652.camel@laptop> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2105 Lines: 46 On Tue, Nov 16, 2010 at 07:59:25PM +0100, Peter Zijlstra wrote: > On Tue, 2010-11-16 at 10:55 -0800, david@lang.hm wrote: > > On Tue, 16 Nov 2010, Paul Menage wrote: > > > > > On Tue, Nov 16, 2010 at 10:21 AM, Peter Zijlstra wrote: > > >> > > >> Not quite the same, you're nesting one level deeper. But the reality is, > > >> not a lot of people will change their userspace. > > > > > > That's a weak argument - not a lot of people will (explicitly) change > > > their kernel either - they'll get a fresh kernel via their distro > > > updates, as they would get userspace updates. So it's only a few > > > people (distros) that actually need to make such a change. > > > > what is the downside of this patch going to be? > > > > people who currently expect all the processes to compete equally will now > > find that they no longer do so. If I am understanding this correctly, this > > could mean that a box that was dedicated to running one application will > > now have that application no longer dominate the system, instead it will > > 'share equally' with the housekeeping apps on the system. > > > > what would need to be done to revert to the prior situation? > > build with: CONFIG_SCHED_AUTOGROUP=n, > boot with: noautogroup or > runtime: echo 0 > /proc/sysctl/kernel/sched_autogroup_enabled > > (although the latter is a lazy one, it won't force existing tasks back > to the root group) I think this might create some issues with controllers which support some kind of upper limit on resource usage. These hidden group can practically consume any amount of resource and because use space tools can't see these, they will not be able to place a limit or control it. If it is done from user space and cgroups are visible, then user can atleast monitor the resource usage and do something about it. Thanks Vivek -- 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/