linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mtk.manpages@gmail.com, Mike Galbraith <efault@gmx.de>,
	Ingo Molnar <mingo@kernel.org>,
	linux-man <linux-man@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: RFC: documentation of the autogroup feature [v2]
Date: Tue, 29 Nov 2016 08:43:33 +0100	[thread overview]
Message-ID: <755aba1b-9bf4-0277-0628-b27e725ee2f9@gmail.com> (raw)
In-Reply-To: <20161125214936.GB3045@worktop.programming.kicks-ass.net>

Hi Peter,

On 11/25/2016 10:49 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 09:54:05PM +0100, Michael Kerrisk (man-pages) wrote:
>> So, part of what I was struggling with was what you meant by cfs-cgroup.
>> Do you mean the CFS bandwidth control features added in Linux 3.2?
> 
> Nope, /me digs around for a bit... around here I suppose:
> 
>  68318b8e0b61 ("Hook up group scheduler with control groups")

Thanks. The pieces are starting to fall into place now.

> 68318b8e0b61 v2.6.24-rc1~151
> 
> But I really have no idea what that looked like.
> 
> 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
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

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.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  reply	other threads:[~2016-11-29  7:43 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 15:59 RFC: documentation of the autogroup feature Michael Kerrisk (man-pages)
2016-11-23 10:33 ` [patch] sched/autogroup: Fix 64bit kernel nice adjustment Mike Galbraith
2016-11-23 13:47   ` Michael Kerrisk (man-pages)
2016-11-23 14:12     ` Mike Galbraith
2016-11-23 14:20       ` Michael Kerrisk (man-pages)
2016-11-23 15:55         ` Mike Galbraith
2016-11-24  6:24   ` [tip:sched/urgent] sched/autogroup: Fix 64-bit kernel nice level adjustment tip-bot for Mike Galbraith
2016-11-23 11:39 ` RFC: documentation of the autogroup feature Mike Galbraith
2016-11-23 13:54   ` Michael Kerrisk (man-pages)
2016-11-23 15:33     ` Mike Galbraith
2016-11-23 16:04       ` Michael Kerrisk (man-pages)
2016-11-23 17:11         ` Mike Galbraith
2016-11-24 21:41           ` RFC: documentation of the autogroup feature [v2] Michael Kerrisk (man-pages)
2016-11-25 12:52             ` Afzal Mohammed
2016-11-25 13:04               ` Michael Kerrisk (man-pages)
2016-11-25 13:02             ` Mike Galbraith
2016-11-25 15:04               ` Michael Kerrisk (man-pages)
2016-11-25 15:48                 ` Michael Kerrisk (man-pages)
2016-11-25 15:51                 ` Mike Galbraith
2016-11-25 16:08                   ` Michael Kerrisk (man-pages)
2016-11-25 16:18                     ` Peter Zijlstra
2016-11-25 16:34                       ` Michael Kerrisk (man-pages)
2016-11-25 20:54                         ` Michael Kerrisk (man-pages)
2016-11-25 21:49                           ` Peter Zijlstra
2016-11-29  7:43                             ` Michael Kerrisk (man-pages) [this message]
2016-11-29 11:46                               ` Peter Zijlstra
2016-11-29 13:44                                 ` Michael Kerrisk (man-pages)
2016-11-25 16:04                 ` Peter Zijlstra
2016-11-25 16:13                   ` Peter Zijlstra
2016-11-25 16:33                   ` Michael Kerrisk (man-pages)
2016-11-25 22:48                     ` Peter Zijlstra
2016-11-23 16:05       ` RFC: documentation of the autogroup feature Michael Kerrisk (man-pages)
2016-11-23 17:19         ` Mike Galbraith
2016-11-23 22:12           ` Michael Kerrisk (man-pages)
2016-11-27 21:13       ` Michael Kerrisk (man-pages)
2016-11-28  1:46         ` Mike Galbraith
     [not found]           ` <1127218a-dd9b-71a8-845d-3a83969632fc@gmail.com>
2016-11-29  9:10             ` Michael Kerrisk (man-pages)
2016-11-29 13:46               ` Mike Galbraith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=755aba1b-9bf4-0277-0628-b27e725ee2f9@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).