From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757222Ab0KPS7e (ORCPT ); Tue, 16 Nov 2010 13:59:34 -0500 Received: from casper.infradead.org ([85.118.1.10]:33774 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755146Ab0KPS7d convert rfc822-to-8bit (ORCPT ); Tue, 16 Nov 2010 13:59:33 -0500 Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups From: Peter Zijlstra To: david@lang.hm Cc: Paul Menage , Lennart Poettering , Linus Torvalds , Dhaval Giani , Mike Galbraith , Vivek Goyal , Oleg Nesterov , Markus Trippelsdorf , Mathieu Desnoyers , Ingo Molnar , LKML , Balbir Singh In-Reply-To: References: <1289820766.16406.45.camel@maggy.simson.net> <1289821590.16406.47.camel@maggy.simson.net> <20101115125716.GA22422@redhat.com> <1289856350.14719.135.camel@maggy.simson.net> <20101116015648.GA11534@redhat.com> <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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Tue, 16 Nov 2010 19:59:25 +0100 Message-ID: <1289933965.2109.652.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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)