On 07/19/2018 09:52 AM, Peter Zijlstra wrote:

On Tue, Jul 03, 2018 at 08:58:23AM -0700, Tejun Heo wrote:

quoted

Hello, Waiman.

On Tue, Jul 03, 2018 at 08:41:31AM +0800, Waiman Long wrote:

quoted

quoted

So, effective changing when enabling partition on a child feels wrong
to me.  It's supposed to contain what's actually allowed to the cgroup
from its parent and that shouldn't change regardless of how those
resources are used.  It's still given to the cgroup from its parent.

Another way to work around this issue is to expose the reserved_cpus in
the parent for holding CPUs that can taken by a chid partition. That
will require adding one more cpuset file for those cgroups that are
partition roots.

Yeah, that should work.

quoted

I don't mind restricting that to the first level children for now. That
does restrict where we can put the container root if we want a separate
partition for a container. Let's hear if others have any objection about
that.

As currently implemented, partioning locks away the cpus which should
be a system level decision, not container level, so it makes sense to
me that it is only available to system root.

I'm terribly confused, what?!

Why would a container not be allowed to create partitions for its
various RT workloads?

As far as I understand, Tejun has some concern about the way that
partitioning works is inconsistent with how other resources are being
managed by cgroup v2 controllers. I adds an incremental patch to
temporarily disable the creation of partition below the first level
children to buy us time so that we can reach a compromise later on what
to do. We can always add features, but taking away features after they
are made available will be hard.

I am fine either way. It is up to you and Tejun to figure out what
should be made available to the users.

Cheers,
Longman


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html