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

On 11/25/2016 04:51 PM, Mike Galbraith wrote:

On Fri, 2016-11-25 at 16:04 +0100, Michael Kerrisk (man-pages) wrote:

quoted

quoted

quoted

       ┌─────────────────────────────────────────────────────┐
       │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?

quoted

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html