linux-kernel - Re: RFC: documentation of the autogroup feature [v2]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Nov 2016 12:46:29 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...nel.org>,
        linux-man <linux-man@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: RFC: documentation of the autogroup feature [v2]

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.