linux-kernel - Re: [RFC 00/60] Coscheduling for Linux

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]

Message-ID: <20181017020933.GC24723@lerouge>
Date:   Wed, 17 Oct 2018 04:09:34 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Jan H. Schönherr <jschoenh@...zon.de>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Rik van Riel <riel@...riel.com>,
        Subhra Mazumdar <subhra.mazumdar@...cle.com>
Subject: Re: [RFC 00/60] Coscheduling for Linux

On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr wrote:
> C) How does it work?
> --------------------
> 
> This patch series introduces hierarchical runqueues, that represent larger
> and larger fractions of the system. By default, there is one runqueue per
> scheduling domain. These additional levels of runqueues are activated by
> the "cosched_max_level=" kernel command line argument. The bottom level is
> 0.
> 
> One CPU per hierarchical runqueue is considered the leader, who is
> primarily responsible for the scheduling decision at this level. Once the
> leader has selected a task group to execute, it notifies all leaders of the
> runqueues below it to select tasks/task groups within the selected task
> group.
> 
> For each task-group, the user can select at which level it should be
> scheduled. If you set "cpu.scheduled" to "1", coscheduling will typically
> happen at core-level on systems with SMT. That is, if one SMT sibling
> executes a task from this task group, the other sibling will do so, too. If
> no task is available, the SMT sibling will be idle. With "cpu.scheduled"
> set to "2" this is extended to the next level, which is typically a whole
> socket on many systems. And so on.  If you feel, that this does not provide
> enough flexibility, you can specify "cosched_split_domains" on the kernel
> command line to create more fine-grained scheduling domains for your
> system.

Have you considered using cpuset to specify the set of CPUs inside which
you want to coschedule task groups in? Perhaps that would be more flexible
and intuitive to control than this cpu.scheduled value.

Unless you require this feature to act always symmetrical through the branches
of a given domain tree?

Thanks.