Re: RFC: documentation of the autogroup feature [v2]

[Michael Kerrisk (man-pages)]

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/