On Mon, 2006-08-21 at 16:39 -0700, Paul Menage wrote: > On 8/7/06, Chandra Seetharaman <[EMAIL PROTECTED]> wrote: > > Hi Paul, > > > > I liked the basic idea of accounting for cpu cycles. But, i see it > > similar to the delay accounting feature that Vatsa pointed to than to be > > part of Resource Groups, as the main purpose of RG is resource > > management than resource monitoring. > > To my mind, those are intimately related - you can't do resource > management without resource monitoring, after all. If it would help
That was the thinking we had originally and that is why e-series CKRM had delay accounting functionality. But later felt that it will be valuable to have the delaystats functionality (monitor _only_ functionality) separated from CKRM so that users can use it independently as well as with CKRM. That is the same rationale behind my suggestion that this functionality to be separate from CKRM/RG itself. BTW, let me make it clear that I see this functionality to be very useful. > fit the RG paradigm better, we could easily turn this into a "CPU > enforcement" resource controller that kills all the processes in the > group when a CPU usage limit is hit. But that seems a bit unnecessary > to me. Killing may be an overkill :). Tasks belonging to the over limit groups can be put in an expired queue and wait there till the next cycle (of allocation). > > > > > Delay accounting stats and RG are intended to be used together. > > Basically, the user space app forms the group and associates it with an > > RG, sums up delay stats for each task in the group to get the collective > > delay information for the group. > > That's a pain, though, since it means that userspace has to do a lot > more /proc scraping, and can't reliably get an accurate value for all > tasks, due to Delay accounting is done in kernel, summing up of data is also done in kernel. Collected data is sent to user space through genetlink interface. No /proc scraping is required. > > - the lack of atomicity of retrieving/adding all the values > - the potentially-changing task membership. > - short-lived processes that use some CPU but are no longer around > when userspace next does an update. > > Paul > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > ckrm-tech mailing list > https://lists.sourceforge.net/lists/listinfo/ckrm-tech -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - [EMAIL PROTECTED] | .......you may get it. ---------------------------------------------------------------------- ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
