On Fri, Jan 20, 2017 at 12:30 AM, Thomas Gleixner <t...@linutronix.de> wrote: > On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote: >> On Thu, Jan 19, 2017 at 9:41 AM, Thomas Gleixner <t...@linutronix.de> wrote: >> > Above you are talking about the same CLOSID and different RMIDS and not >> > about changing both. >> >> The scenario I talked about implies changing CLOSID without affecting >> monitoring. >> It happens when the allocation needs for a thread/cgroup/CPU change >> dynamically. Forcing to change the RMID together with the CLOSID would >> give wrong monitoring values unless the old RMID is kept around until >> becomes free, which is ugly and would waste a RMID. > > When the allocation needs for a resource control group change, then we > simply update the allocation constraints of that group without chaning the > CLOSID. So everything just stays the same. > > If you move entities to a different group then of course the CLOSID > changes and then it's a different story how to deal with monitoring. > >> > To gather any useful information for both CPU1 and T1 you need TWO >> > RMIDs. Everything else is voodoo and crystal ball analysis and we are not >> > going to support that. >> > >> >> Correct. Yet, having two RMIDs to monitor the same task/cgroup/CPU >> just because the CLOSID changed is wasteful. > > Again, the CLOSID only changes if you move entities to a different resource > control group and in that case the RMID change is the least of your worries. > >> Correct. But there may not be a fixed CLOSID association if loads >> exhibit dynamic behavior and/or system load changes dynamically. > > So, you really want to move entities around between resource control groups > dynamically? I'm not seing why you would want to do that, but I'm all ear > to get educated on that.
No, I don't want to move entities across resource control groups. I was confused by the idea of CLOSIDs being married to control groups, but now is clear even to me that that was never the intention. Thanks, David > > Thanks, > > tglx
