Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1527655 > unrolled thread
| Started by | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| First post | 2016-11-22 17:20 +0100 |
| Last post | 2016-11-29 14:50 +0100 |
| Articles | 18 on this page of 38 — 5 participants |
Back to article view | Back to linux.kernel
RFC: documentation of the autogroup feature "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-22 17:20 +0100
[patch] sched/autogroup: Fix 64bit kernel nice adjustment Mike Galbraith <efault@gmx.de> - 2016-11-23 11:40 +0100
Re: [patch] sched/autogroup: Fix 64bit kernel nice adjustment "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-23 14:50 +0100
Re: [patch] sched/autogroup: Fix 64bit kernel nice adjustment Mike Galbraith <efault@gmx.de> - 2016-11-23 15:20 +0100
Re: [patch] sched/autogroup: Fix 64bit kernel nice adjustment "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-23 15:30 +0100
Re: [patch] sched/autogroup: Fix 64bit kernel nice adjustment Mike Galbraith <efault@gmx.de> - 2016-11-23 17:00 +0100
[tip:sched/urgent] sched/autogroup: Fix 64-bit kernel nice level adjustment tip-bot for Mike Galbraith <tipbot@zytor.com> - 2016-11-24 07:30 +0100
Re: RFC: documentation of the autogroup feature Mike Galbraith <efault@gmx.de> - 2016-11-23 12:50 +0100
Re: RFC: documentation of the autogroup feature "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-23 15:00 +0100
Re: RFC: documentation of the autogroup feature Mike Galbraith <efault@gmx.de> - 2016-11-23 16:40 +0100
Re: RFC: documentation of the autogroup feature "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-23 17:10 +0100
Re: RFC: documentation of the autogroup feature Mike Galbraith <efault@gmx.de> - 2016-11-23 18:20 +0100
Re: RFC: documentation of the autogroup feature "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-23 23:50 +0100
Re: RFC: documentation of the autogroup feature "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-23 17:10 +0100
Re: RFC: documentation of the autogroup feature Mike Galbraith <efault@gmx.de> - 2016-11-23 18:20 +0100
RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-24 22:50 +0100
Re: RFC: documentation of the autogroup feature [v2] Afzal Mohammed <afzal.mohd.ma@gmail.com> - 2016-11-25 14:00 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-25 14:10 +0100
Re: RFC: documentation of the autogroup feature [v2] Mike Galbraith <efault@gmx.de> - 2016-11-25 14:30 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-25 16:30 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-25 16:50 +0100
Re: RFC: documentation of the autogroup feature [v2] Mike Galbraith <efault@gmx.de> - 2016-11-25 17:00 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-25 17:20 +0100
Re: RFC: documentation of the autogroup feature [v2] Peter Zijlstra <peterz@infradead.org> - 2016-11-25 17:20 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-25 17:40 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-25 22:00 +0100
Re: RFC: documentation of the autogroup feature [v2] Peter Zijlstra <peterz@infradead.org> - 2016-11-25 22:50 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-29 08:50 +0100
Re: RFC: documentation of the autogroup feature [v2] Peter Zijlstra <peterz@infradead.org> - 2016-11-29 12:50 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-29 14:50 +0100
Re: RFC: documentation of the autogroup feature [v2] Peter Zijlstra <peterz@infradead.org> - 2016-11-25 17:10 +0100
Re: RFC: documentation of the autogroup feature [v2] Peter Zijlstra <peterz@infradead.org> - 2016-11-25 17:20 +0100
Re: RFC: documentation of the autogroup feature [v2] "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-25 17:40 +0100
Re: RFC: documentation of the autogroup feature [v2] Peter Zijlstra <peterz@infradead.org> - 2016-11-25 23:50 +0100
Re: RFC: documentation of the autogroup feature "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-27 22:20 +0100
Re: RFC: documentation of the autogroup feature Mike Galbraith <efault@gmx.de> - 2016-11-28 02:50 +0100
Re: RFC: documentation of the autogroup feature "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-11-29 10:20 +0100
Re: RFC: documentation of the autogroup feature Mike Galbraith <efault@gmx.de> - 2016-11-29 14:50 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-25 16:50 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHqVb-2o9-3@gated-at.bofh.it> |
| In reply to | #1530354 |
On 11/25/2016 04:04 PM, Michael Kerrisk (man-pages) wrote: > Hi Mike, > > On 11/25/2016 02:02 PM, Mike Galbraith wrote: >>> ┌─────────────────────────────────────────────────────┐ >>> │FIXME │ >>> ├─────────────────────────────────────────────────────┤ >>> │How do the nice value of a process and the nice │ >>> │value of an autogroup interact? Which has priority? │ >>> │ │ >>> │It *appears* that the autogroup nice value is used │ >>> │for CPU distribution between task groups, and that │ >>> │the process nice value has no effect there. (I.e., │ >>> │suppose two autogroups each contain a CPU-bound │ >>> │process, with one process having nice==0 and the │ >>> │other having nice==19. It appears that they each │ >>> │get 50% of the CPU.) It appears that the process │ >>> │nice value has effect only with respect to schedul‐ │ >>> │ing relative to other processes in the *same* auto‐ │ >>> │group. Is this correct? │ >>> └─────────────────────────────────────────────────────┘ >> >> Yup, entity nice level affects distribution among peer entities. > > Huh! I only just learned about this via my experiments while > investigating autogroups. > > How long have things been like this? Always? (I don't think > so.) Since the arrival of CFS? Since the arrival of > autogrouping? (I'm guessing not.) Since some other point? > (When?) Okay, things changed sometime after 2.6.31, at least. (Just tested on an old box.) So, presumably with the arrival of either CFS or autogrouping? Next comment certainly applies: > It seems to me that this renders the traditional process > nice pretty much useless. (I bet I'm not the only one who'd > be surprised by the current behavior.) Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | Mike Galbraith <efault@gmx.de> |
|---|---|
| Date | 2016-11-25 17:00 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHr4R-2rt-3@gated-at.bofh.it> |
| In reply to | #1530354 |
On Fri, 2016-11-25 at 16:04 +0100, Michael Kerrisk (man-pages) wrote: > > > ┌─────────────────────────────────────────────────────┐ > > > │FIXME │ > > > ├─────────────────────────────────────────────────────┤ > > > │How do the nice value of a process and the nice │ > > > │value of an autogroup interact? Which has priority? │ > > > │ │ > > > │It *appears* that the autogroup nice value is used │ > > > │for CPU distribution between task groups, and that │ > > > │the process nice value has no effect there. (I.e., │ > > > │suppose two autogroups each contain a CPU-bound │ > > > │process, with one process having nice==0 and the │ > > > │other having nice==19. It appears that they each │ > > > │get 50% of the CPU.) It appears that the process │ > > > │nice value has effect only with respect to schedul‐ │ > > > │ing relative to other processes in the *same* auto‐ │ > > > │group. Is this correct? │ > > > └─────────────────────────────────────────────────────┘ > > > > Yup, entity nice level affects distribution among peer entities. > > Huh! I only just learned about this via my experiments while > investigating autogroups. > > How long have things been like this? Always? (I don't think > so.) Since the arrival of CFS? Since the arrival of > autogrouping? (I'm guessing not.) Since some other point? > (When?) Always. Before CFS there just were no non-peers :) > It seems to me that this renders the traditional process > nice pretty much useless. (I bet I'm not the only one who'd > be surprised by the current behavior.) Yup, group scheduling is not a single edged sword, those don't exist. Box wide nice loss is not the only thing that can bite you, fairness, whether group or task oriented cuts both ways. -Mike
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-25 17:20 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHroe-2Rp-17@gated-at.bofh.it> |
| In reply to | #1530377 |
On 11/25/2016 04:51 PM, Mike Galbraith wrote: > On Fri, 2016-11-25 at 16:04 +0100, Michael Kerrisk (man-pages) wrote: > >>>> ┌─────────────────────────────────────────────────────┐ >>>> │FIXME │ >>>> ├─────────────────────────────────────────────────────┤ >>>> │How do the nice value of a process and the nice │ >>>> │value of an autogroup interact? Which has priority? │ >>>> │ │ >>>> │It *appears* that the autogroup nice value is used │ >>>> │for CPU distribution between task groups, and that │ >>>> │the process nice value has no effect there. (I.e., │ >>>> │suppose two autogroups each contain a CPU-bound │ >>>> │process, with one process having nice==0 and the │ >>>> │other having nice==19. It appears that they each │ >>>> │get 50% of the CPU.) It appears that the process │ >>>> │nice value has effect only with respect to schedul‐ │ >>>> │ing relative to other processes in the *same* auto‐ │ >>>> │group. Is this correct? │ >>>> └─────────────────────────────────────────────────────┘ >>> >>> Yup, entity nice level affects distribution among peer entities. >> >> Huh! I only just learned about this via my experiments while >> investigating autogroups. >> >> How long have things been like this? Always? (I don't think >> so.) Since the arrival of CFS? Since the arrival of >> autogrouping? (I'm guessing not.) Since some other point? >> (When?) > > Always. Before CFS there just were no non-peers :) Well that's one way of looking at it. So, the change that I'm talking about came in 2.6.32 with CFS then? >> It seems to me that this renders the traditional process >> nice pretty much useless. (I bet I'm not the only one who'd >> be surprised by the current behavior.) > > Yup, group scheduling is not a single edged sword, those don't exist. > Box wide nice loss is not the only thing that can bite you, fairness, > whether group or task oriented cuts both ways. Understood. But again I'll say, I bet a lot of old-time users (and maybe many newer) would be surprised by the fact that nice(1) / setpriority(2) have effectively been rendered no-ops in many use cases. At the very least, it'd have been nice if someone had sent a man pages patch or at least a note... Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-11-25 17:20 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHroe-2Rp-15@gated-at.bofh.it> |
| In reply to | #1530401 |
On Fri, Nov 25, 2016 at 05:08:44PM +0100, Michael Kerrisk (man-pages) wrote: > On 11/25/2016 04:51 PM, Mike Galbraith wrote: > Well that's one way of looking at it. So, the change > that I'm talking about came in 2.6.32 with CFS then? cfs-cgroup landed later I think, and it was fairly wobbly in the first few release (as per usual I'd say for major features).
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-25 17:40 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHrHz-2XN-23@gated-at.bofh.it> |
| In reply to | #1530403 |
On 11/25/2016 05:18 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 05:08:44PM +0100, Michael Kerrisk (man-pages) wrote: >> On 11/25/2016 04:51 PM, Mike Galbraith wrote: >> Well that's one way of looking at it. So, the change >> that I'm talking about came in 2.6.32 with CFS then? > > cfs-cgroup landed later I think, and it was fairly wobbly in the first > few release (as per usual I'd say for major features). So I've been searching git logs and elsewhere, but didn't yet find a likely commit(s). Any clues what I should be looking for. I'd like this info, because while documenting the changes, I'd also like to document when they occurred. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-25 22:00 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHvLc-5sv-5@gated-at.bofh.it> |
| In reply to | #1530421 |
Hi Peter, On 11/25/2016 05:34 PM, Michael Kerrisk (man-pages) wrote: > On 11/25/2016 05:18 PM, Peter Zijlstra wrote: >> On Fri, Nov 25, 2016 at 05:08:44PM +0100, Michael Kerrisk (man-pages) wrote: >>> On 11/25/2016 04:51 PM, Mike Galbraith wrote: >>> Well that's one way of looking at it. So, the change >>> that I'm talking about came in 2.6.32 with CFS then? >> >> cfs-cgroup landed later I think, and it was fairly wobbly in the first >> few release (as per usual I'd say for major features). > > So I've been searching git logs and elsewhere, but didn't yet > find a likely commit(s). Any clues what I should be looking for. > I'd like this info, because while documenting the changes, I'd > also like to document when they occurred. 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? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-11-25 22:50 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHwxz-5Zv-3@gated-at.bofh.it> |
| In reply to | #1530526 |
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")
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.
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-29 08:50 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sILkR-5lO-9@gated-at.bofh.it> |
| In reply to | #1530542 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-11-29 12:50 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sIP58-7Uu-33@gated-at.bofh.it> |
| In reply to | #1531973 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-29 14:50 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sIQXf-F4-23@gated-at.bofh.it> |
| In reply to | #1532208 |
Hi Peter,
On 29 November 2016 at 12:46, Peter Zijlstra <peterz@infradead.org> wrote:
> 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.
Actually, it looks to me like it is the default. But that isn't really
the point. Even if the default was off, it's the way of things that
distros will generally default "on" things, because some users want
them. That's a repeated and to be expected pattern.
>> 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.
I understand. It's just unfortunate that the (as far as I can see) the
implications were not fully considered before making the change. Such
consideration often springs out of writing comprehensive
documentation, I find ;-).
>> 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.
Sure, but cgroups is different. It requires explicit action by the
ueser (creating cgroups) to see the behavior.
With autogroups, the change kicks in on the desktop without the user
needing to do anything, and changes desktop behavior in a way that was
unexpected.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-11-25 17:10 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHrex-2Lj-15@gated-at.bofh.it> |
| In reply to | #1530354 |
On Fri, Nov 25, 2016 at 04:04:25PM +0100, Michael Kerrisk (man-pages) wrote:
> >> ┌─────────────────────────────────────────────────────┐
> >> │FIXME │
> >> ├─────────────────────────────────────────────────────┤
> >> │How do the nice value of a process and the nice │
> >> │value of an autogroup interact? Which has priority? │
> >> │ │
> >> │It *appears* that the autogroup nice value is used │
> >> │for CPU distribution between task groups, and that │
> >> │the process nice value has no effect there. (I.e., │
> >> │suppose two autogroups each contain a CPU-bound │
> >> │process, with one process having nice==0 and the │
> >> │other having nice==19. It appears that they each │
> >> │get 50% of the CPU.) It appears that the process │
> >> │nice value has effect only with respect to schedul‐ │
> >> │ing relative to other processes in the *same* auto‐ │
> >> │group. Is this correct? │
> >> └─────────────────────────────────────────────────────┘
> >
> > Yup, entity nice level affects distribution among peer entities.
>
> Huh! I only just learned about this via my experiments while
> investigating autogroups.
>
> How long have things been like this? Always? (I don't think
> so.) Since the arrival of CFS? Since the arrival of
> autogrouping? (I'm guessing not.) Since some other point?
> (When?)
Ever since cfs-cgroup, this is a fundamental design point of cgroups,
and has therefore always been the case for autogroups (as that is
nothing more than an application of the cgroup code).
> It seems to me that this renders the traditional process
> nice pretty much useless. (I bet I'm not the only one who'd
> be surprised by the current behavior.)
Its really rather fundamental to how the whole hierarchical things
works.
CFS is a weighted fair queueing scheduler; this means each entity
receives:
w_i
dt_i = dt --------
\Sum w_j
CPU
______/ \______
/ | | \
A B C D
So if each entity {A,B,C,D} has equal weight, then they will receive
equal time. Explicitly, for C you get:
w_C
dt_C = dt -----------------------
(w_A + w_B + w_C + w_D)
Extending this to a hierarchy, we get:
CPU
______/ \______
/ | | \
A B C D
/ \
E F
Where C becomes a 'server' for entities {E,F}. The weight of C does not
depend on its child entities. This way the time of {E,F} becomes a
straight product of their ratio with C. That is; the whole thing
becomes, where l denotes the level in the hierarchy and i an
entity on that level:
l w_g,i
dt_l,i = dt \Prod ----------
g=0 \Sum w_g,j
Or more concretely, for E:
w_E
dt_1,E = dt_0,C -----------
(w_E + w_F)
w_C w_E
= dt ----------------------- -----------
(w_A + w_B + w_C + w_D) (w_E + w_F)
And this 'trivially' extends to SMP, with the tricky bit being that the
sums over all entities end up being machine wide, instead of per CPU,
which is a real and royal pain for performance.
Note that this property, where the weight of the server entity is
independent from its child entities is a desired feature. Without that
it would be impossible to control the relative weights of groups, and
that is the sole parameter of the WFQ model.
It is also why Linus so likes autogroups, each session competes equally
amongst one another.
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-11-25 17:20 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHrod-2Rp-3@gated-at.bofh.it> |
| In reply to | #1530383 |
On Fri, Nov 25, 2016 at 05:04:56PM +0100, Peter Zijlstra wrote: > That is; the whole thing > becomes, where l denotes the level in the hierarchy and i an > entity on that level: > > l w_g,i > dt_l,i = dt \Prod ---------- > g=0 \Sum w_g,j > > > Or more concretely, for E: > > w_E > dt_1,E = dt_0,C ----------- > (w_E + w_F) > > w_C w_E > = dt ----------------------- ----------- > (w_A + w_B + w_C + w_D) (w_E + w_F) > And this also immediately shows one of the 'problems' with it. Since we don't have floating point in kernel, these fractions are evaluated with fixed-point arithmetic. Traditionally (and on 32bit) we use 10bit fixed point, recently we switched to 20bit for 64bit machines. That change is what bit you on the nice testing. But it also means that once we run out of fractional bits things go wobbly. The fractions, as per the above, increase the deeper the group hierarchy goes but are also affected by the number of CPUs in the system (not immediately represented in that equation). Not to mention that many scheduler operations become O(depth) in cost, which also hurts. An obvious example being task selection, we pick a runnable entity for each level, until the resulting entity has no further children (iow. is a task).
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-25 17:40 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHrHz-2XN-5@gated-at.bofh.it> |
| In reply to | #1530383 |
Hi Peter,
On 11/25/2016 05:04 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 04:04:25PM +0100, Michael Kerrisk (man-pages) wrote:
>>>> ┌─────────────────────────────────────────────────────┐
>>>> │FIXME │
>>>> ├─────────────────────────────────────────────────────┤
>>>> │How do the nice value of a process and the nice │
>>>> │value of an autogroup interact? Which has priority? │
>>>> │ │
>>>> │It *appears* that the autogroup nice value is used │
>>>> │for CPU distribution between task groups, and that │
>>>> │the process nice value has no effect there. (I.e., │
>>>> │suppose two autogroups each contain a CPU-bound │
>>>> │process, with one process having nice==0 and the │
>>>> │other having nice==19. It appears that they each │
>>>> │get 50% of the CPU.) It appears that the process │
>>>> │nice value has effect only with respect to schedul‐ │
>>>> │ing relative to other processes in the *same* auto‐ │
>>>> │group. Is this correct? │
>>>> └─────────────────────────────────────────────────────┘
>>>
>>> Yup, entity nice level affects distribution among peer entities.
>>
>> Huh! I only just learned about this via my experiments while
>> investigating autogroups.
>>
>> How long have things been like this? Always? (I don't think
>> so.) Since the arrival of CFS? Since the arrival of
>> autogrouping? (I'm guessing not.) Since some other point?
>> (When?)
>
> Ever since cfs-cgroup,
Okay. That begs the question still though.
> this is a fundamental design point of cgroups,
> and has therefore always been the case for autogroups (as that is
> nothing more than an application of the cgroup code).
Understood.
>> It seems to me that this renders the traditional process
>> nice pretty much useless. (I bet I'm not the only one who'd
>> be surprised by the current behavior.)
>
> Its really rather fundamental to how the whole hierarchical things
> works.
>
> CFS is a weighted fair queueing scheduler; this means each entity
> receives:
>
> w_i
> dt_i = dt --------
> \Sum w_j
>
>
> CPU
> ______/ \______
> / | | \
> A B C D
>
>
> So if each entity {A,B,C,D} has equal weight, then they will receive
> equal time. Explicitly, for C you get:
>
>
> w_C
> dt_C = dt -----------------------
> (w_A + w_B + w_C + w_D)
>
>
> Extending this to a hierarchy, we get:
>
>
> CPU
> ______/ \______
> / | | \
> A B C D
> / \
> E F
>
> Where C becomes a 'server' for entities {E,F}. The weight of C does not
> depend on its child entities. This way the time of {E,F} becomes a
> straight product of their ratio with C. That is; the whole thing
> becomes, where l denotes the level in the hierarchy and i an
> entity on that level:
>
> l w_g,i
> dt_l,i = dt \Prod ----------
> g=0 \Sum w_g,j
>
>
> Or more concretely, for E:
>
> w_E
> dt_1,E = dt_0,C -----------
> (w_E + w_F)
>
> w_C w_E
> = dt ----------------------- -----------
> (w_A + w_B + w_C + w_D) (w_E + w_F)
>
>
> And this 'trivially' extends to SMP, with the tricky bit being that the
> sums over all entities end up being machine wide, instead of per CPU,
> which is a real and royal pain for performance.
Okay -- you're really quite the ASCII artist. And somehow,
I think you needed to compose the mail in LaTeX. But thanks
for the detail. It's helpful, for me at least.
> Note that this property, where the weight of the server entity is
> independent from its child entities is a desired feature. Without that
> it would be impossible to control the relative weights of groups, and
> that is the sole parameter of the WFQ model.
>
> It is also why Linus so likes autogroups, each session competes equally
> amongst one another.
I get it. But, the behavior changes for the process nice value are
undocumented, and they should be documented. I understand
what the behavior change was. But not yet when.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-11-25 23:50 +0100 |
| Subject | Re: RFC: documentation of the autogroup feature [v2] |
| Message-ID | <sHxtD-6Eq-1@gated-at.bofh.it> |
| In reply to | #1530414 |
On Fri, Nov 25, 2016 at 05:33:23PM +0100, Michael Kerrisk (man-pages) wrote: > Okay -- you're really quite the ASCII artist. And somehow, > I think you needed to compose the mail in LaTeX. But thanks > for the detail. It's helpful, for me at least. Hehe, its been a while since I did LaTeX, so I'd probably make a mess of it :-) Glad my ramblings made sense. > > Note that this property, where the weight of the server entity is > > independent from its child entities is a desired feature. Without that > > it would be impossible to control the relative weights of groups, and > > that is the sole parameter of the WFQ model. > > > > It is also why Linus so likes autogroups, each session competes equally > > amongst one another. > > I get it. But, the behavior changes for the process nice value are > undocumented, and they should be documented. I understand > what the behavior change was. But not yet when. Well, its all undocumented -- I suppose you're about to go fix that :-) But think of it differently, think of the group as a container, then the behaviour inside the container is exactly as expected.
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-27 22:20 +0100 |
| Message-ID | <sIf1D-1fZ-5@gated-at.bofh.it> |
| In reply to | #1528517 |
Hi Mike,
On 11/23/2016 04:33 PM, Mike Galbraith wrote:
> On Wed, 2016-11-23 at 14:54 +0100, Michael Kerrisk (man-pages) wrote:
>> Hi Mike,
[...]
>> Actually, can you define for me what the root task group is, and
>> why it exists? That may be worth some words in this man page.
>
> I don't think we need group scheduling details, there's plenty of
> documentation elsewhere for those who want theory. Autogroup is for
> those who don't want to have to care (which is also why it should have
> never grown nice knob).
Actually, the more I think about this, the more I think we *do*
need a few details on group scheduling. Otherwise, it's difficult
to explain to the use why nice(1) no longer works as traditionally
expected.
Here's my attempt to define the root task group:
* If autogrouping is disabled, then all processes in the root CPU
cgroup form a scheduling group (sometimes called the "root task
group").
Can you improve on this?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | Mike Galbraith <efault@gmx.de> |
|---|---|
| Date | 2016-11-28 02:50 +0100 |
| Message-ID | <sIjeV-3OA-1@gated-at.bofh.it> |
| In reply to | #1530931 |
On Sun, 2016-11-27 at 22:13 +0100, Michael Kerrisk (man-pages) wrote: > Here's my attempt to define the root task group: > > * If autogrouping is disabled, then all processes in the root CPU > cgroup form a scheduling group (sometimes called the "root task > group"). > > Can you improve on this? A task group is a set of percpu runqueues. The root task group is the top level set in a hierarchy of such sets when group scheduling is enabled, or the only set when group scheduling is not enabled. The autogroup hierarchy has a depth of one, ie all autogroups are peers who's common parent is the root task group. -Mike
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2016-11-29 10:20 +0100 |
| Message-ID | <sIMJY-6yn-31@gated-at.bofh.it> |
| In reply to | #1530983 |
[Resending because of bounces from the lists. (Somehow my mailer
messed up the MIME labeling)]
Hi Mike,
On 11/28/2016 02:46 AM, Mike Galbraith wrote:
> On Sun, 2016-11-27 at 22:13 +0100, Michael Kerrisk (man-pages) wrote:
>
>> Here's my attempt to define the root task group:
>>
>> * If autogrouping is disabled, then all processes in the root CPU
>> cgroup form a scheduling group (sometimes called the "root task
>> group").
>>
>> Can you improve on this?
The below is helpful, but...
> A task group is a set of percpu runqueues.
The explanation needs really to be in terms of what user-space
understands and sees. "Runqueues" are a kernel scheduler implementation
detail.
> The root task group is the
> top level set in a hierarchy of such sets when group scheduling is
> enabled, or the only set when group scheduling is not enabled. The
> autogroup hierarchy has a depth of one, ie all autogroups are peers
> who's common parent is the root task group.
Let's try and go further. How's this:
When scheduling non-real-time processes (i.e., those scheduled
under the SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE policies), the
CFS scheduler employs a technique known as "group scheduling", if
the kernel was configured with the CONFIG_FAIR_GROUP_SCHED option
(which is typical).
Under group scheduling, threads are scheduled in "task groups".
Task groups have a hierarchical relationship, rooted under the
initial task group on the system, known as the "root task group".
Task groups are formed in the following circumstances:
* All of the threads in a CPU cgroup form a task group. The par‐
ent of this task group is the task group of the corresponding
parent cgroup.
* If autogrouping is enabled, then all of the threads that are
(implicitly) placed in an autogroup (i.e., the same session, as
created by setsid(2)) form a task group. Each new autogroup is
thus a separate task group. The root task group is the parent
of all such autogroups.
* If autogrouping is enabled, then the root task group consists
of all processes in the root CPU cgroup that were not otherwise
implicitly placed into a new autogroup.
* If autogrouping is disabled, then the root task group consists
of all processes in the root CPU cgroup.
* If group scheduling was disabled (i.e., the kernel was config‐
ured without CONFIG_FAIR_GROUP_SCHED), then all of the pro‐
cesses on the system are notionally placed in a single task
group.
[To be followed by a discussion of the nice value and task groups]
?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
[toc] | [prev] | [next] | [standalone]
| From | Mike Galbraith <efault@gmx.de> |
|---|---|
| Date | 2016-11-29 14:50 +0100 |
| Message-ID | <sIQXg-F4-45@gated-at.bofh.it> |
| In reply to | #1532024 |
On Tue, 2016-11-29 at 10:10 +0100, Michael Kerrisk (man-pages) wrote: > Let's try and go further. How's this: > > When scheduling non-real-time processes (i.e., those scheduled > under the SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE policies), the > CFS scheduler employs a technique known as "group scheduling", if > the kernel was configured with the CONFIG_FAIR_GROUP_SCHED option > (which is typical). > > Under group scheduling, threads are scheduled in "task groups". > Task groups have a hierarchical relationship, rooted under the > initial task group on the system, known as the "root task group". > Task groups are formed in the following circumstances: > > * All of the threads in a CPU cgroup form a task group. The par‐ > ent of this task group is the task group of the corresponding > parent cgroup. > > * If autogrouping is enabled, then all of the threads that are > (implicitly) placed in an autogroup (i.e., the same session, as > created by setsid(2)) form a task group. Each new autogroup is > thus a separate task group. The root task group is the parent > of all such autogroups. > > * If autogrouping is enabled, then the root task group consists > of all processes in the root CPU cgroup that were not otherwise > implicitly placed into a new autogroup. > > * If autogrouping is disabled, then the root task group consists > of all processes in the root CPU cgroup. > > * If group scheduling was disabled (i.e., the kernel was config‐ > ured without CONFIG_FAIR_GROUP_SCHED), then all of the pro‐ > cesses on the system are notionally placed in a single task > group. Notionally works for me. -Mike
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web