On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> agreed, we need to be reporting idle time in (milli)seconds, although
> the requirement we had was to report it back in percentage. I guess the
> percentage figure can be derived from the raw idle time number.
>
> How about:
>
>
On Tue, Oct 23, 2007 at 07:28:22PM -0700, Paul Menage wrote:
> > Good point. I think we need to subtract out the time it was waiting on
> > runqueue
> > when calculating idle time.
> >
> > |--- . . . . . . -...---|
> > t0 t1t2
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > Suppose you have two cgroups that would each want to use, say, 55% of
> > a CPU - technically they should each be regarded as having 45% idle
> > time, but if they run on a the same CPU the chances are that they will
> > both always hav
On Tue, Oct 23, 2007 at 09:41:49AM -0700, Paul Menage wrote:
> > > Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> > > milliseconds for that cgroup's tasks
> >
> > It would be nice to split this into user and sys time at some point.
>
> Sounds reasonable - but does CFS track th
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> > milliseconds for that cgroup's tasks
>
> It would be nice to split this into user and sys time at some point.
Sounds reasonable - but does CFS track this?
> We have
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> Report CPU usage in CFS Cgroup directories
>
> Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> milliseconds for that cgroup's tasks
It would be nice to split this into user and sys time at some point.
We have also
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> + for_each_possible_cpu(i) {
> + unsigned long flags;
> + spin_lock_irqsave(&tg->cfs_rq[i]->rq->lock, flags);
A simpler form of this would be just:
spin_lock_irqsave(&cpu_rq(i)->lock, flags)
On Mon, Oct 22, 2007 at 11:06:54PM -0700, Paul Menage wrote:
> > > + for_each_possible_cpu(i) {
> > > + unsigned long flags;
> > > + spin_lock_irqsave(&tg->cfs_rq[i]->rq->lock, flags);
> >
> > Is the lock absolutely required here?
>
> I'm not sure, I was hoping you or I
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, without notify_on_release you can never be sure if a new task
> got added to the control group or if someone acquired a reference
> to it. I can't think of a safe way of removing control groups/cpusets
> without using notify_on_release.
Paul Menage wrote:
> On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> Well, most people who care about deletion will use the notify_on_release
>> callback and retry.
>
> I'm not convinced this is true. Certainly the userspace approaches
> we're developing at Google don't (currently) use not
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, most people who care about deletion will use the notify_on_release
> callback and retry.
I'm not convinced this is true. Certainly the userspace approaches
we're developing at Google don't (currently) use notify_on_release.
Paul
-
To
Paul Menage wrote:
> On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>> Using cgroup_mutex is certainly possible for now, although more
>> heavy-weight than I'd like long term. Using css_get isn't the right
>> approach, I think - we shouldn't be able to cause an rmdir to fail due
>> to a concur
On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> Using cgroup_mutex is certainly possible for now, although more
> heavy-weight than I'd like long term. Using css_get isn't the right
> approach, I think - we shouldn't be able to cause an rmdir to fail due
> to a concurrent read.
>
OK, the o
On 10/22/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> I think we also need the notion of load, like we have in cpu_acct.c
Yes, a notion of load would be good - but the "load" calculated by
cpu_acct.c isn't all that useful yet - it's just a total of the CPU
cycles used in the 10 second time inte
On 10/22/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> > +static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
> > +{
> > + struct task_group *tg = cgroup_tg(cgrp);
> > + int i;
> > + u64 res = 0;
> > +
Paul Menage wrote:
> Report CPU usage in CFS Cgroup directories
>
> Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> milliseconds for that cgroup's tasks
>
> This replaces the "example CPU Accounting CGroup subsystem" that
> was merged into mainline last week.
>
> Signed-off-b
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> +static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
> +{
> + struct task_group *tg = cgroup_tg(cgrp);
> + int i;
> + u64 res = 0;
> + for_each_possible_cpu(i) {
> + unsigned long flags;
> +
Report CPU usage in CFS Cgroup directories
Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
milliseconds for that cgroup's tasks
This replaces the "example CPU Accounting CGroup subsystem" that
was merged into mainline last week.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
18 matches
Mail list logo
