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