Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

From: Paul Turner <pjt@google.com>
To: Tejun Heo <tj@kernel.org>
Cc: Patrick Bellasi <patrick.bellasi@arm.com>,
	"Joel Fernandes (Google)" <joel.opensrc@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-pm@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller
Date: Thu, 30 Mar 2017 14:13:04 -0700	[thread overview]
Message-ID: <CAPM31RLJKgnNLv9-fpwxHNNNxfGv2NoyWHD3kUivU+RSgoR5Dw@mail.gmail.com> (raw)
In-Reply-To: <20170323183937.GC5953@htj.duckdns.org>

There is one important, fundamental difference here:
 {cfs,rt}_{period,runtime}_us is a property that applies to a group of
threads, it can be sub-divided.
We can consume 100ms of quota either by having one thread run for
100ms, or 2 threads running for 50ms.

This is not true for capacity.  It's a tag that affects the individual
threads it's applied to.
I'm also not sure if it's a hard constraint.  For example, suppose we
set a max that is smaller than a "big" cpu on an asymmetric system.
In the case that the faster CPU is relatively busy, but still
opportunistically available, we would still want to schedule it there.

This definitely seems to make more sense as a per-thread interface in
its current form.