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:   Wed, 23 Nov 2016 14:54:17 +0100
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Mike Galbraith <efault@....de>
Cc:     mtk.manpages@...il.com, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        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

Hi Mike,

First off, I better say that I'm not at all intimate with the details
of the scheduler, so bear with me...

On 11/23/2016 12:39 PM, Mike Galbraith wrote:
> On Tue, 2016-11-22 at 16:59 +0100, Michael Kerrisk (man-pages) wrote:
> 
>>        ┌─────────────────────────────────────────────────────┐
>>        │FIXME                                                │
>>        ├─────────────────────────────────────────────────────┤
>>        │The following is a little vague. Does it need to  be │
>>        │made more precise?                                   │
>>        └─────────────────────────────────────────────────────┘
>>        The CFS scheduler employs an algorithm that distributes the CPU
>>        across task groups.  As a result of this  algorithm,  the  pro‐
>>        cesses  in task groups that contain multiple CPU-intensive pro‐
>>        cesses are in effect disfavored by the scheduler.
> 
> Mmmm, they're actually equalized (modulo smp fairness goop), but I see
> what you mean.

I couldn't quite grok that sentence. My problem is resolving "they".
Do you mean: "the CPU scheduler equalizes the distribution of
CPU cycles across task groups"?

> 
>>        A process's autogroup (task group) membership can be viewed via
>>        the file /proc/[pid]/autogroup:
>>
>>            $ cat /proc/1/autogroup
>>            /autogroup-1 nice 0
>>
>>        This  file  can  also be used to modify the CPU bandwidth allo‐
>>        cated to a task group.  This is done by writing a number in the
>>        "nice"  range  to  the file to set the task group's nice value.
>>        The allowed range is from +19 (low priority) to -20 (high  pri‐
>>        ority).   Note that all values in this range cause a task group
>>        to be further disfavored by the scheduler, with  -20  resulting
>>        in  the  scheduler  mildy  disfavoring  the  task group and +19
>>        greatly disfavoring it.
> 
> Group nice levels exactly work the same as task nice levels, ie
> negative nice increases share, positive nice decreases it relative to
> the default nice 0.

Yes, got it now.

>>        ┌─────────────────────────────────────────────────────┐
>>        │FIXME                                                │
>>        ├─────────────────────────────────────────────────────┤
>>        │Regarding the previous paragraph...  My tests  indi‐ │
>>        │cate  that writing *any* value to the autogroup file │
>>        │causes the task group to get a lower priority.
> 
> (patchlet.. 

Writing documentation finds bugs. Who knew? ;-)

> I'd prefer to whack the knob, but like the on/off switch,
> it may be in use, so I guess we're stuck with it)
> 
>>        ┌─────────────────────────────────────────────────────┐
>>        │FIXME                                                │
>>        ├─────────────────────────────────────────────────────┤
>>        │Is the following correct? Does the statement need to │
>>        │be  more  precise? (E.g., in precisely which circum‐ │
>>        │stances does the use of cgroups override autogroup?) │
>>        └─────────────────────────────────────────────────────┘
>>        The use of the cgroups(7) CPU controller overrides  the  effect
>>        of autogrouping.
> 
> Correct, autogroup defers to cgroups.  Perhaps mention that moving a
> task back to the root task group will result in the autogroup again
> taking effect.

In what circumstances does a process get moved back to the root 
task group? 

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.

>>        ┌─────────────────────────────────────────────────────┐
>>        │FIXME                                                │
>>        ├─────────────────────────────────────────────────────┤
>>        │What  needs to be said about autogroup and real-time │
>>        │tasks?                                               │
>>        └─────────────────────────────────────────────────────┘
> 
> That it does not group realtime tasks, they are auto-deflected to the
> root task group.

Okay. Thanks.

Cheers,

Michael


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ