Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1200222
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management |
| Date | 2015-08-04 20:40 +0200 |
| Message-ID | <pTPi2-1RC-15@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <pHyFY-2Jd-23@gated-at.bofh.it> <pS202-83R-17@gated-at.bofh.it> <pSkgh-19Y-3@gated-at.bofh.it> <pT4j7-SF-1@gated-at.bofh.it> <pTwIq-8j-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hello, On Mon, Aug 03, 2015 at 05:32:50PM -0300, Marcelo Tosatti wrote: > You really want to specify the cache configuration "at once": > having process-A exclusive access to 2MB of cache at all times, > and process-B 4MB exclusive, means you can't have process-C use 4MB of > cache exclusively (consider 8MB cache machine). This is akin to arguing for implementing cpuset without sched_setaffinity() or any other facility to adjust affinity. People have been using affinity fine before cgroups. Sure, certain things are cumbersome but cgroups isn't a replacement for a proper API. > > cgroups is not a superset of a programmable interface. It has > > distinctive disadvantages and not a substitute with hirearchy support > > for regular systemcall-like interface. I don't think it makes sense > > to go full-on hierarchical cgroups when we don't have basic interface > > which is likely to cover many use cases better. A syscall-like > > interface combined with a tool similar to taskset would cover a lot in > > a more accessible way. > > How are you going to specify sharing of portions of cache by two sets > of tasks with a syscall interface? Again, think about how people have been using CPU affinity. > > cpuset-style allocation can be easier for things like this but that > > should be an addition on top not the one and only interface. How is > > it gonna handle if multiple threads of a process want to restrict > > cache usages to avoid stepping on each other's toes? Delegate the > > subdirectory and let the process itself open it and write to files to > > configure when there isn't even a way to atomically access the > > process's own directory or a way to synchronize against migration? > > One would preconfigure that in advance - but you are right, a > syscall interface is more flexible in that respect. I'm not trying to say cgroup controller would be useless but the current approach seems somewhat backwards and over-engineered. Can't we just start with something simple? e.g. a platform device driver that allows restricting cache usage of a target thread (be that self or ptraceable target)? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-07-30 21:50 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Marcelo Tosatti <mtosatti@redhat.com> - 2015-07-31 17:20 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-02 18:30 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Marcelo Tosatti <mtosatti@redhat.com> - 2015-08-04 00:50 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Marcelo Tosatti <mtosatti@redhat.com> - 2015-08-04 15:00 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-04 20:40 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-04 20:40 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Vikas Shivappa <vikas.shivappa@intel.com> - 2015-07-31 18:30 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-02 18:40 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Vikas Shivappa <vikas.shivappa@intel.com> - 2015-08-04 21:00 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-04 21:10 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Vikas Shivappa <vikas.shivappa@intel.com> - 2015-08-05 04:30 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-05 17:50 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Vikas Shivappa <vikas.shivappa@intel.com> - 2015-08-06 23:00 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-07 16:50 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Matt Fleming <matt@codeblueprint.co.uk> - 2015-08-05 14:30 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Tejun Heo <tj@kernel.org> - 2015-08-05 18:20 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Marcelo Tosatti <mtosatti@redhat.com> - 2015-08-06 02:30 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Vikas Shivappa <vikas.shivappa@intel.com> - 2015-08-06 22:50 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Marcelo Tosatti <mtosatti@redhat.com> - 2015-08-07 15:20 +0200
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management Marcelo Tosatti <mtosatti@redhat.com> - 2015-08-18 02:30 +0200
csiph-web