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

[Shaohua Li]

On Fri, Sep 09, 2016 at 06:03:12PM +0000, Luck, Tony wrote:
> > I don't think this is convenient, but it's ok. Now if we create a new thread
> > between 1 and 2, the new thread is in group1. The new thread pid isn't in the
> > pid list we found in 1, so after 2, the new thread still is in group 1. Truely
> > sysadmin can repeat the step 1 & 2 and move the new thread to group 2, but
> > there is always chance the process creates new thread between 1 and 2, and the
> > new thread remains in group 1. There is no guarantee we can safely move a
> > process from one group to another.
> 
> In general this is true.  But don't most threaded applications have a single thread that
> is the one that spawns new threads? Typically the first thread.  Once that is moved,
> any new threads will inherit the new group. So there won't be a neverending mopping
> operation trying to catch up.
> 
> Even this seems outside the expected usage model for CAT where we expect the
> system admin to partition the cache between resource groups at boot time and
> then assign jobs (or containers, or VMs) to resource groups when they are created.

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.

Thanks,
Shaohua