Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC 00/60] Coscheduling for Linux
To:     "=?UTF-8?Q?Jan_H._Sch=c3=b6nherr?=" <jschoenh@amazon.de>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>
Cc:     linux-kernel@vger.kernel.org
References: <20180907214047.26914-1-jschoenh@amazon.de>
From:   Subhra Mazumdar <subhra.mazumdar@oracle.com>
Message-ID: <3336974a-38f7-41dd-25a7-df05e077444f@oracle.com>
Date:   Mon, 17 Sep 2018 17:33:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180907214047.26914-1-jschoenh@amazon.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 09/07/2018 02:39 PM, Jan H. Schönherr wrote:
> This patch series extends CFS with support for coscheduling. The
> implementation is versatile enough to cover many different coscheduling
> use-cases, while at the same time being non-intrusive, so that behavior of
> legacy workloads does not change.
>
> Peter Zijlstra once called coscheduling a "scalability nightmare waiting to
> happen". Well, with this patch series, coscheduling certainly happened.
> However, I disagree on the scalability nightmare. :)
>
> In the remainder of this email, you will find:
>
> A) Quickstart guide for the impatient.
> B) Why would I want this?
> C) How does it work?
> D) What can I *not* do with this?
> E) What's the overhead?
> F) High-level overview of the patches in this series.
>
> Regards
> Jan
>
>
> A) Quickstart guide for the impatient.
> --------------------------------------
>
> Here is a quickstart guide to set up coscheduling at core-level for
> selected tasks on an SMT-capable system:
>
> 1. Apply the patch series to v4.19-rc2.
> 2. Compile with "CONFIG_COSCHEDULING=y".
> 3. Boot into the newly built kernel with an additional kernel command line
>     argument "cosched_max_level=1" to enable coscheduling up to core-level.
> 4. Create one or more cgroups and set their "cpu.scheduled" to "1".
> 5. Put tasks into the created cgroups and set their affinity explicitly.
> 6. Enjoy tasks of the same group and on the same core executing
>     simultaneously, whenever they are executed.
>
> You are not restricted to coscheduling at core-level. Just select higher
> numbers in steps 3 and 4. See also further below for more information, esp.
> when you want to try higher numbers on larger systems.
>
> Setting affinity explicitly for tasks within coscheduled cgroups is
> currently necessary, as the load balancing portion is still missing in this
> series.
>
I don't get the affinity part. If I create two cgroups by giving them only
cpu shares (no cpuset) and set their cpu.scheduled=1, will this ensure
co-scheduling of each group on core level for all cores in the system?

Thanks,
Subhra