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
