On Sat, Sep 10, 2016 at 12:36:57AM +0000, Yu, Fenghua wrote: > > > Hmm, I don't know how applications are going to use the interface. > > > Nobody knows it right now. But we do have some candicate workloads > > > which want to configure the cache partition at runtime, so it's not > > > just a boot time stuff. I'm wondering why we have such limitation. The > > > framework is there, it's quite easy to implement process move in > > > kernel but fairly hard to get it right in userspace. > > > > You are correct - if there is a need for this, it would be better done in > > the > > kernel. > > > > I'm just not sure how to explain both a "procs" and "tasks" interface file > > in a > > way that won't confuse people. > > > > We have: > > > > # echo {task-id} > tasks > > .... adds a single task to this resource group # cat tasks > > ... shows all the tasks in this resource group > > > > and you want: > > > > # echo {process-id} > procs > > ... adds all threads in {process-id} to this resource group # cat procs > > ... shows all processes (like "cat tasks" above, but only shows main > > thread in > > a multi-threads process) > > The advantage of "tasks" is user can allocate each thread into its own > partition. > The advantage of "procs" is convenience for user to just allocate thread group > lead pid and rest of the thread group members go with the lead. > > If no "procs" is really inconvenience, we may support "procs" in future. > > One way to implement this is we can extend the current interface to accept > a resctrl file system mount parameter to switch b/w "procs" and "tasks" during > mount time. So the file sytem has either "procs" or "tasks" during run time. > I don't think it's right to have both of them at the same time in the file > system.
A mount option doesn't make sense, which just creates more trouble. What's wrong to have both of 'procs' and 'tasks' at the same time, like cgroup? I think it's more natural to support both. As for the content of 'procs' and 'tasks', we could follow how cgroup handle them. Thanks, Shaohua