OpenVZ Forum - RDF feed
type: channel
items: Revert for cgroups CPU accounting subsystem patch
items: Re: Revert for cgroups CPU accounting subsystem patch
items: [PATCH] sched: cpu accounting controller
items: Re: [PATCH] sched: cpu accounting controller
items: [PATCH] sched: cpu accounting controller (V2)
items: Re: [PATCH] sched: cpu accounting controller (V2)

Revert for cgroups CPU accounting subsystem patch
type: item
description: Hi Linus, Please can you revert commit 62d0df64065e7c135d0002f069444fbdfc64768f, entitled "Task Control Groups: example CPU accounting subsystem" ? This was originally intended as a simple initial example of how to create a control groups subsystem; it wasn't intended for mainline, but I didn't make this clear enough to Andrew. The CFS cgroup subsystem now has better functionality for the per-cgroup usage accounting (based directly on CFS stats) than the "usage" status file in this patch, and the "load" status file is rather simplistic - although having a per-cgroup load average report would be a useful feature, I don't believe this patch actually provides it. If it gets into the final 2.6.24 we'd probably have to support this interface for ever. Thanks, Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-11-13T05:25:32-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Mon, Nov 12, 2007 at 09:25:32PM -0800, Paul Menage wrote: > Hi Linus, > > Please can you revert commit 62d0df64065e7c135d0002f069444fbdfc64768f, > entitled "Task Control Groups: example CPU accounting subsystem" ? Hi Paul, On second thoughts, this may be a usefull controller of its own. Say I just want to "monitor" usage (for accounting purpose) of a group of tasks, but don't want to control their cpu consumption, then cpuacct controller would come in handy. -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-11-13T05:51:46-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Nov 12, 2007 10:00 PM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > On second thoughts, this may be a usefull controller of its own. > Say I just want to "monitor" usage (for accounting purpose) of a group of > tasks, but don't want to control their cpu consumption, then cpuacct > controller would come in handy. > That's plausible, but having two separate ways of tracking and reporting the CPU usage of a cgroup seems wrong. How bad would it be in your suggested case if you just give each cgroup the same weight? So there would be fair scheduling between cgroups, which seems as reasonable as any other choice in the event that the CPU is contended. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-11-13T06:05:24-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: Paul Menage wrote: > On Nov 12, 2007 10:00 PM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: >> On second thoughts, this may be a usefull controller of its own. >> Say I just want to "monitor" usage (for accounting purpose) of a group of >> tasks, but don't want to control their cpu consumption, then cpuacct >> controller would come in handy. >> > > That's plausible, but having two separate ways of tracking and > reporting the CPU usage of a cgroup seems wrong. > > How bad would it be in your suggested case if you just give each > cgroup the same weight? So there would be fair scheduling between > cgroups, which seems as reasonable as any other choice in the event > that the CPU is contended. > Right now, one of the limitations of the CPU controller is that the moment you create another control group, the bandwidth gets divided by the default number of shares. We can't create groups just for monitoring. cpu_acct fills this gap. I think in the long run, we should move the helper functions into cpu_acct.c and the interface logic into kernel/sched.c (cpu controller). -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-11-13T07:00:20-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Nov 12, 2007 11:00 PM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > > Right now, one of the limitations of the CPU controller is that > the moment you create another control group, the bandwidth gets > divided by the default number of shares. We can't create groups > just for monitoring. Could we get around this with, say, a flag that always treats a CFS schedulable entity as having a weight equal to the number of runnable tasks in it? So CPU bandwidth would be shared between groups in proportion to the number of runnable tasks, which would distribute the cycles approximately equivalently to them all being separate schedulable entities. > cpu_acct fills this gap. Agreed, but not in the right way IMO. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-11-13T07:10:11-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: Paul Menage wrote: > On Nov 12, 2007 11:00 PM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote: >> Right now, one of the limitations of the CPU controller is that >> the moment you create another control group, the bandwidth gets >> divided by the default number of shares. We can't create groups >> just for monitoring. > > Could we get around this with, say, a flag that always treats a CFS > schedulable entity as having a weight equal to the number of runnable > tasks in it? So CPU bandwidth would be shared between groups in > proportion to the number of runnable tasks, which would distribute the > cycles approximately equivalently to them all being separate > schedulable entities. > I think it's a good hack, but not sure about the complexity to implement the code. I worry that if the number of tasks increase (say run into thousands for one or more groups and a few groups have just a few tasks), we'll lose out on accuracy. >> cpu_acct fills this gap. > > Agreed, but not in the right way IMO. > I think we already have the code, we need to make it more useful and reusable. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-11-13T07:29:59-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Nov 12, 2007 11:29 PM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > > I think it's a good hack, but not sure about the complexity to implement > the code. I worry that if the number of tasks increase (say run into > thousands for one or more groups and a few groups have just a few > tasks), we'll lose out on accuracy. But for the case we're looking at, you've already said that you don't care much about actually controlling CPU, just monitoring it. So what does it matter if the CPU sharing isn't perfectly accurate? I don't think that you're painting a realistic scenario. > > I think we already have the code, we need to make it more useful and > reusable. In that case we should take the existing cpu_acct code out of 2.6.24 until the API has been made more useful and reusable, so that we don't have to support it for ever. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-11-13T07:34:47-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Mon, Nov 12, 2007 at 10:05:24PM -0800, Paul Menage wrote: > On Nov 12, 2007 10:00 PM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > > On second thoughts, this may be a usefull controller of its own. > > Say I just want to "monitor" usage (for accounting purpose) of a group of > > tasks, but don't want to control their cpu consumption, then cpuacct > > controller would come in handy. > > > > That's plausible, but having two separate ways of tracking and > reporting the CPU usage of a cgroup seems wrong. > > How bad would it be in your suggested case if you just give each > cgroup the same weight? That's still introducing a deviation from the normal behavior we would have had we allowed all tasks to be part of the same "control" group/runqueue. For ex: using nice value to vary bandwidth between tasks makes sense if they are all part of the same group. Also an application with more tasks will get more cpu power (as intended) compared to another app with less tasks, provided they are all part of the same group. Regarding your concern about tracking cpu usage in different ways, it could be mitigated if we have cpuacct controller track usage as per information present in a task's sched entity structure (tsk->se.sum_exec_runtime) i.e call cpuacct_charge() from __update_curr() which would accumulate the execution time of the group in a SMP friendly manner (i.e dump it in a per-cpu per-group counter first and then aggregate to a global per-group counter). This will let account and control grouping to be independent if desired. What do you think? > So there would be fair scheduling between > cgroups, which seems as reasonable as any other choice in the event > that the CPU is contended. -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-11-13T07:37:40-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Tue, Nov 13, 2007 at 12:59:59PM +0530, Balbir Singh wrote: > Paul Menage wrote: > > On Nov 12, 2007 11:00 PM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > >> Right now, one of the limitations of the CPU controller is that > >> the moment you create another control group, the bandwidth gets > >> divided by the default number of shares. We can't create groups > >> just for monitoring. > > > > Could we get around this with, say, a flag that always treats a CFS > > schedulable entity as having a weight equal to the number of runnable > > tasks in it? So CPU bandwidth would be shared between groups in > > proportion to the number of runnable tasks, which would distribute the > > cycles approximately equivalently to them all being separate > > schedulable entities. > > > > I think it's a good hack, but not sure about the complexity to implement > the code. I agree that it would be adding unnecessary complexity, just to meet the accounting needs. Thinking of it more, this requirement to "group tasks for only accounting purpose" may be required for other resources (mem, io, network etc) as well? Should we have a generic accounting controller which can provide these various resource usgae stats for a group (cpu, mem etc) by iterating thr' the task list for the group and summing up the corresponding stats already present in task structure? -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-11-13T07:49:02-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Nov 12, 2007 11:48 PM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > > Regarding your concern about tracking cpu usage in different ways, it > could be mitigated if we have cpuacct controller track usage as per > information present in a task's sched entity structure > (tsk->se.sum_exec_runtime) i.e call cpuacct_charge() from > __update_curr() which would accumulate the execution time of the > group in a SMP friendly manner (i.e dump it in a per-cpu per-group counter > first and then aggregate to a global per-group counter). That seems more reasonable than the current approach in cpu_acct.c Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-11-13T07:57:03-00:00

Re: Revert for cgroups CPU accounting subsystem patch
type: item
description: On Nov 12, 2007 11:59 PM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > > Thinking of it more, this requirement to "group tasks for only accounting > purpose" may be required for other resources (mem, io, network etc) as well? > Should we have a generic accounting controller which can provide these > various resource usgae stats for a group (cpu, mem etc) by iterating thr' the > task list for the group and summing up the corresponding stats already present > in task structure? In theory it could certainly be useful - but it can only be done if something in the kernel is already keeping track of resources on a per-task basis. This works for CPU, but isn't really possible for memory without doing something lame like just adding up the tasks' RSS values (since the page accounting is the hard part - limiting is easy once you have accounting). Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-11-13T07:59:50-00:00

[PATCH] sched: cpu accounting controller
type: item
description: On Mon, Nov 12, 2007 at 11:57:03PM -0800, Paul Menage wrote: > > Regarding your concern about tracking cpu usage in different ways, it > > could be mitigated if we have cpuacct controller track usage as per > > information present in a task's sched entity structure > > (tsk->se.sum_exec_runtime) i.e call cpuacct_charge() from > > __update_curr() which would accumulate the execution time of the > > group in a SMP friendly manner (i.e dump it in a per-cpu per-group counter > > first and then aggregate to a global per-group counter). > > That seems more reasonable than the current approach in cpu_acct.c Paul, Sorry about the delay in getting back to this thread. I realized very recently that cpuacct controller has been removed from Linus's tree and have attempted to rework it as per our discussions. Linus/Ingo, Commit cfb5285660aad4931b2ebbfa902ea48a37dfffa1 removed a usefull feature for us, which provided a cpu accounting resource controller. This feature would be usefull if someone wants to group tasks only for accounting purpose and doesnt really want to exercise any control over their cpu consumption. The patch below reintroduces the feature. It is based on Paul Menage's original patch (Commit 62d0df64065e7c135d0002f069444fbdfc64768f), with these differences: - Removed load average information. I felt it needs more thought (esp to deal with SMP and virtualized platforms) and can be added for 2.6.25 after more discussions. - Convert group cpu usage to be nanosecond accurate (as rest of the cfs stats are) and invoke cpuacct_charge() from the respective scheduler classes The patch also modifies the cpu controller not to provide the same accounting information. Todo: - Make the accounting scalable on SMP systems (perhaps for 2.6.25) Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- include/linux/cgroup_subsys.h | 6 ++ include/linux/cpu_acct.h | 14 +++++ init/Kconfig | 7 ++ kernel/Makefile | 1 kernel/cpu_acct.c | 103 ++++++++++++++++++++++++++++++++++++++…
creator: Srivatsa Vaddagiri
date: 2007-11-29T19:11:48-00:00

Re: [PATCH] sched: cpu accounting controller
type: item
description: * Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > Paul, > Sorry about the delay in getting back to this thread. I realized > very recently that cpuacct controller has been removed from Linus's tree > and have attempted to rework it as per our discussions. > > Linus/Ingo, > Commit cfb5285660aad4931b2ebbfa902ea48a37dfffa1 removed a > usefull feature for us, which provided a cpu accounting resource > controller. This feature would be usefull if someone wants to group > tasks only for accounting purpose and doesnt really want to exercise > any control over their cpu consumption. ok, this looks certainly doable for v2.6.24. I've added it to the scheduler fixes queue and will let it brew there for a few days and send it to Linus after that if everything goes fine - unless anyone objects. This is pre-existing, tested code so the risk is small. Ingo _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Ingo Molnar
date: 2007-11-29T19:20:58-00:00

Re: [PATCH] sched: cpu accounting controller
type: item
description: On Thu, Nov 29, 2007 at 08:20:58PM +0100, Ingo Molnar wrote: > ok, this looks certainly doable for v2.6.24. I've added it to the > scheduler fixes queue and will let it brew there for a few days and send > it to Linus after that if everything goes fine - unless anyone objects. Thanks. -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-11-29T19:28:48-00:00

Re: [PATCH] sched: cpu accounting controller
type: item
description: On Fri, 30 Nov 2007 00:47:37 +0530 Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > On Mon, Nov 12, 2007 at 11:57:03PM -0800, Paul Menage wrote: > > > Regarding your concern about tracking cpu usage in different ways, it > > > could be mitigated if we have cpuacct controller track usage as per > > > information present in a task's sched entity structure > > > (tsk->se.sum_exec_runtime) i.e call cpuacct_charge() from > > > __update_curr() which would accumulate the execution time of the > > > group in a SMP friendly manner (i.e dump it in a per-cpu per-group counter > > > first and then aggregate to a global per-group counter). > > > > That seems more reasonable than the current approach in cpu_acct.c > > Paul, > Sorry about the delay in getting back to this thread. I realized > very recently that cpuacct controller has been removed from Linus's tree > and have attempted to rework it as per our discussions. > > Linus/Ingo, > Commit cfb5285660aad4931b2ebbfa902ea48a37dfffa1 removed a usefull > feature for us, which provided a cpu accounting resource controller. This > feature would be usefull if someone wants to group tasks only for accounting > purpose and doesnt really want to exercise any control over their cpu > consumption. > > The patch below reintroduces the feature. It is based on Paul Menage's > original patch (Commit 62d0df64065e7c135d0002f069444fbdfc64768f), with > these differences: > > - Removed load average information. I felt it needs > more thought (esp to deal with SMP and virtualized platforms) > and can be added for 2.6.25 after more discussions. > - Convert group cpu usage to be nanosecond accurate (as rest > of the cfs stats are) and invoke cpuacct_charge() from > the respective scheduler classes > > The patch also modifies the cpu controller not to provide the same > accounting information. > > ... > > - Make the accounting scalable on SMP systems (perhaps > for 2.6.25) That sounds like a rather important todo. How bad is it now? > Index: cu…
creator: akpm
date: 2007-11-29T19:30:35-00:00

Re: [PATCH] sched: cpu accounting controller
type: item
description: On Thu, Nov 29, 2007 at 11:30:35AM -0800, Andrew Morton wrote: > > - Make the accounting scalable on SMP systems (perhaps > > for 2.6.25) > > That sounds like a rather important todo. How bad is it now? It is indeed an important todo. Right now we take a per-group global lock on every accounting update (which can be very frequent) and hence it is pretty bad. Ingo had expressed the need to reintroduce this patch asap and hence I resent it w/o attacking the scalability part. I will take a shot at scalability enhancements tomorrow and send it as a separate patch. > > +struct cpuacct { > > + struct cgroup_subsys_state css; > > + spinlock_t lock; > > + /* total time used by this class (in nanoseconds) */ > > + u64 time; > > +}; > > + > > +struct cgroup_subsys cpuacct_subsys; > > This can be made static. This symbol is needed in kernel/cgroup.c file, where it does this: static struct cgroup_subsys *subsys[] = { #include <linux/cgroup_subsys.h> }; and hence it cant be static. Thanks for the rest of your comments. I have fixed them in this version below: Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- include/linux/cgroup_subsys.h | 6 ++ include/linux/cpu_acct.h | 14 +++++ init/Kconfig | 7 ++ kernel/Makefile | 1 kernel/cpu_acct.c | 101 ++++++++++++++++++++++++++++++++++++++++++ kernel/sched.c | 27 ----------- kernel/sched_fair.c | 5 ++ kernel/sched_rt.c | 1 8 files changed, 136 insertions(+), 26 deletions(-) Index: current/include/linux/cgroup_subsys.h =================================================================== --- current.orig/include/linux/cgroup_subsys.h +++ current/include/linux/cgroup_subsys.h @@ -11,6 +11,12 @@ SUBSYS(cpuset) #endif +#ifdef CONFIG_CGROUP_CPUACCT +SUBSYS(cpuacct) +#endif + +/* */ + /* */ #ifdef CONFIG_CGROUP_DEBUG Index: current/include/linux/cpu_acct.h =================================================================== --- /dev/null +++ current/include/linux/cpu_acct.h @@ -0,0 +1,14 @@ + +#ifndef _LINUX_CPU_ACCT_H +#define _LI…
creator: Srivatsa Vaddagiri
date: 2007-11-29T20:08:51-00:00

[PATCH] sched: cpu accounting controller (V2)
type: item
description: On Fri, Nov 30, 2007 at 01:48:33AM +0530, Srivatsa Vaddagiri wrote: > It is indeed an important todo. Right now we take a per-group global > lock on every accounting update (which can be very frequent) and hence > it is pretty bad. > > Ingo had expressed the need to reintroduce this patch asap and hence I resent > it w/o attacking the scalability part. I will take a shot at scalability > enhancements tomorrow and send it as a separate patch. Here's V2 of the cpu acccounting controller patch, which makes accounting scale better on SMP systems by splitting the usage counter to be per-cpu. ----> Commit cfb5285660aad4931b2ebbfa902ea48a37dfffa1 removed a useful feature for us, which provided a cpu accounting resource controller. This feature would be useful if someone wants to group tasks only for accounting purpose and doesnt really want to exercise any control over their cpu consumption. The patch below reintroduces the feature. It is based on Paul Menage's original patch (Commit 62d0df64065e7c135d0002f069444fbdfc64768f), with these differences: - Removed load average information. I felt it needs more thought (esp to deal with SMP and virtualized platforms) and can be added for 2.6.25 after more discussions. - Convert group cpu usage to be nanosecond accurate (as rest of the cfs stats are) and invoke cpuacct_charge() from the respective scheduler classes - Make accounting scalable on SMP systems by splitting the usage counter to be per-cpu - Move the code from kernel/cpu_acct.c to kernel/sched.c (since the code is not big enough to warrant a new file and also this rightly needs to live inside the scheduler. Also things like accessing rq->lock while reading cpu usage becomes easier if the code lived in kernel/sched.c) The patch also modifies the cpu controller not to provide the same accounting information. Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- include/linux/cgroup_subsys.h | 7 + init/Kconfig | 7 + kernel/sched.c | 155 ++++++++++++++++++++++++…
creator: Srivatsa Vaddagiri
date: 2007-11-30T12:32:37-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: * Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > Here's V2 of the cpu acccounting controller patch, which makes > accounting scale better on SMP systems by splitting the usage counter > to be per-cpu. thanks, applied. But you dont seem to have incorporated all of the review feedback from Andrew. (such as making cpuacct_subsys static) Ingo _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Ingo Molnar
date: 2007-11-30T12:35:13-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: Srivatsa Vaddagiri wrote: [snip] > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-11-30T12:45:43-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: On Fri, Nov 30, 2007 at 01:35:13PM +0100, Ingo Molnar wrote: > * Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > > > Here's V2 of the cpu acccounting controller patch, which makes > > accounting scale better on SMP systems by splitting the usage counter > > to be per-cpu. > > thanks, applied. But you dont seem to have incorporated all of the > review feedback from Andrew. (such as making cpuacct_subsys static) cpuacct_subsys can't be made static, as I have pointed out at http://marc.info/?l=linux-kernel&m=119636730930886. Other than that, AFAICS, rest of Andrew's comments have been taken care of. If there are any remaining that I have over-looked, I had be happy to fix them. -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-11-30T13:09:03-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: * Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > On Fri, Nov 30, 2007 at 01:35:13PM +0100, Ingo Molnar wrote: > > * Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > > > > > Here's V2 of the cpu acccounting controller patch, which makes > > > accounting scale better on SMP systems by splitting the usage counter > > > to be per-cpu. > > > > thanks, applied. But you dont seem to have incorporated all of the > > review feedback from Andrew. (such as making cpuacct_subsys static) > > cpuacct_subsys can't be made static, as I have pointed out at > http://marc.info/?l=linux-kernel&m=119636730930886. [...] ah, ok - i missed that. Ingo _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Ingo Molnar
date: 2007-11-30T13:34:55-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: * Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > Srivatsa Vaddagiri wrote: > [snip] > > > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> > > > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> thx. Have you done targeted testing of it as well? The (v2) patch is in sched-devel.git: git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git Ingo _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Ingo Molnar
date: 2007-11-30T13:53:31-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: Ingo Molnar wrote: > * Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > >> Srivatsa Vaddagiri wrote: >> [snip] >> >>> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> >>> >> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> > > thx. Have you done targeted testing of it as well? The (v2) patch is in > sched-devel.git: > > git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git > > Ingo Vatsa tested the patches. I am going to independently test them as well. In the process of getting the test setup up and running and doing some testing. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-11-30T14:00:01-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: * Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > > thx. Have you done targeted testing of it as well? The (v2) patch is > > in sched-devel.git: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git > > Ingo > > Tested the patches on top of 2.6.24-rc3. The patches work fine. Ran > some simple tests like cpuspin (spin on the cpu), ran several tasks in > the same group and timed them. Compared their time stamps with > cpuacct.usage. > > Tested-by: Balbir Singh <balbir@linux.vnet.ibm.com> thanks! Ingo _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Ingo Molnar
date: 2007-11-30T19:46:47-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: Hi Vatsa, Thanks, this looks pretty good. On Nov 30, 2007 4:42 AM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > > - Removed load average information. I felt it needs more thought (esp > to deal with SMP and virtualized platforms) and can be added for > 2.6.25 after more discussions. The "load" value was never a load average, it was just a count of the % cpu time used in the previous fixed window of time, updated at the end of each window. Maybe we can instead do something based tracking the length of the run queue for the cgroup? Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-12-01T07:48:15-00:00

Re: [PATCH] sched: cpu accounting controller (V2)
type: item
description: Paul Menage wrote: > Hi Vatsa, > > Thanks, this looks pretty good. > > On Nov 30, 2007 4:42 AM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: >> - Removed load average information. I felt it needs more thought (esp >> to deal with SMP and virtualized platforms) and can be added for >> 2.6.25 after more discussions. > > The "load" value was never a load average, it was just a count of the > % cpu time used in the previous fixed window of time, updated at the > end of each window. > > Maybe we can instead do something based tracking the length of the run > queue for the cgroup? > > Paul Length of the runqueue gives no idea of the weight of the tasks on the runqueue. I still prefer to have a top'ish view of the load on the system. The load average can be extracted using container group statistics. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-12-01T09:51:09-00:00