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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
