RE: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

[Yu, Fenghua]

> > 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.

Is this the right way to go?

Thanks.

-Fenghua