Messages in this thread | | | Date | Thu, 30 Jul 2015 15:44:58 -0400 | From | Tejun Heo <> | Subject | Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management |
| |
Hello, Vikas.
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote: > This patch adds a cgroup subsystem for Intel Resource Director > Technology(RDT) feature and Class of service(CLOSid) management which is > part of common RDT framework. This cgroup would eventually be used by > all sub-features of RDT and hence be associated with the common RDT > framework as well as sub-feature specific framework. However current > patch series only adds cache allocation sub-feature specific code. > > When a cgroup directory is created it has a CLOSid associated with it > which is inherited from its parent. The Closid is mapped to a > cache_mask which represents the L3 cache allocation to the cgroup. > Tasks belonging to the cgroup get to fill the cache represented by the > cache_mask.
First of all, I apologize for being so late. I've been thinking about it but the thoughts didn't quite crystalize (which isn't to say that it's very crystal now) until recently. If I understand correctly, there are a couple suggested use cases for explicitly managing cache usage.
1. Pinning known hot areas of memory in cache.
2. Explicitly regulating cache usage so that cacheline allocation can be better than CPU itself doing it.
#1 isn't part of this patchset, right? Is there any plan for working towards this too?
For #2, it is likely that the targeted use cases would involve threads of a process or at least cooperating processes and having a simple API which just goes "this (or the current) thread is only gonna use this part of cache" would be a lot easier to use and actually beneficial.
I don't really think it makes sense to implement a fully hierarchical cgroup solution when there isn't the basic affinity-adjusting interface and it isn't clear whether fully hierarchical resource distribution would be necessary especially given that the granularity of the target resource is very coarse.
I can see that how cpuset would seem to invite this sort of usage but cpuset itself is more of an arbitrary outgrowth (regardless of history) in terms of resource control and most things controlled by cpuset already have countepart interface which is readily accessible to the normal applications.
Given that what the feature allows is restricting usage rather than granting anything exclusively, a programmable interface wouldn't need to worry about complications around priviledges while being able to reap most of the benefits in an a lot easier way. Am I missing something?
Thanks.
-- tejun
| |