From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756595AbcK2Lri (ORCPT ); Tue, 29 Nov 2016 06:47:38 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:54239 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755176AbcK2Lra (ORCPT ); Tue, 29 Nov 2016 06:47:30 -0500 Date: Tue, 29 Nov 2016 12:46:29 +0100 From: Peter Zijlstra To: "Michael Kerrisk (man-pages)" Cc: Mike Galbraith , Ingo Molnar , linux-man , lkml , Thomas Gleixner Subject: Re: RFC: documentation of the autogroup feature [v2] Message-ID: <20161129114629.GG3092@twins.programming.kicks-ass.net> References: <1480078973.4075.58.camel@gmx.de> <1480089063.4075.80.camel@gmx.de> <20161125161810.GR3092@twins.programming.kicks-ass.net> <2cc53b76-668b-edf1-6aa7-e6cb5a9801e1@gmail.com> <20161125214936.GB3045@worktop.programming.kicks-ass.net> <755aba1b-9bf4-0277-0628-b27e725ee2f9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <755aba1b-9bf4-0277-0628-b27e725ee2f9@gmail.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 29, 2016 at 08:43:33AM +0100, Michael Kerrisk (man-pages) wrote: > > > > In any case, for the case of autogroup, the behaviour has always been, > > autogroups came quite late. > > This ("the behavior has always been") isn't quite true. Yes, group > scheduling has been around since Linux 2.6.24, but in terms of the > semantics of the thread nice value, there was no visible change > then, *unless* explicit action was taken to create cgroups. > > The arrival of autogroups in Linux 2.6.38 was different. > With this feature enabled (which is the default), task I don't think the SCHED_AUTOGROUP symbol is default y, most distros might have default enabled it, but that's not something I can help. > groups were implicitly created *without the user needing to > do anything*. Thus, [two terminal windows] == [two task groups] > and in those two terminal windows, nice(1) on a CPU-bound > command in one terminal did nothing in terms of improving > CPU access for a CPU-bound tasks running on the other terminal > window. > > Put more succinctly: in Linux 2.6.38, autogrouping broke nice(1) > for many use cases. > > Once I came to that simple summary it was easy to find multiple > reports of problems from users: > > http://serverfault.com/questions/405092/nice-level-not-working-on-linux > http://superuser.com/questions/805599/nice-has-no-effect-in-linux-unless-the-same-shell-is-used > https://www.reddit.com/r/linux/comments/1c4jew/nice_has_no_effect/ > http://stackoverflow.com/questions/10342470/process-niceness-priority-setting-has-no-effect-on-linux > > Someone else quickly pointed out to me another such report: > > https://bbs.archlinux.org/viewtopic.php?id=149553 Well, none of that ever got back to me, so again, nothing I could do about that. > And when I quickly surveyed a few more or less savvy Linux users > in one room, most understood what nice does, but none of them knew > about the behavior change wrought by autogroup. > > I haven't looked at all of the mails in the old threads that > discussed the implementation of this feature, but so far none of > those that I saw mentioned this behavior change. It's unfortunate > that it never even got documented. Well, when we added the feature people (most notable Linus) understood what cgroups did. So no surprises for any of us.