All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Venkatesh Pallipadi <venki@google.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul Menage <menage@google.com>,
	linux-kernel@vger.kernel.org, Paul Turner <pjt@google.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH 0/4] Finer granularity and task/cgroup irq time accounting
Date: Tue, 24 Aug 2010 18:17:26 +0530	[thread overview]
Message-ID: <20100824124726.GQ4684@balbir.in.ibm.com> (raw)
In-Reply-To: <1282650835.2605.2629.camel@laptop>

* Peter Zijlstra <peterz@infradead.org> [2010-08-24 13:53:55]:

> On Tue, 2010-08-24 at 17:08 +0530, Balbir Singh wrote:
> > 
> > The point is for containers it is more likely to give the right answer
> > and so on. Yes, the results are not 100% accurate. 
> 
> Consider one group heavily dirtying pages, it stuffs the IO queues full
> and gets blocked on IO completion. Since the CPU is then free to
> schedule something else we start running things from another group,
> those IO completions will come in while we run other group and get
> accounted to other group -- FAIL.
> 
> s/group/task/ etc..
> 
> That just really doesn't work, accounting async work, esp stuff that is
> not under software control it very tricky indeed.

Yes, we don't have sufficient context to charge the correct context. I
think openvz has some technology there, we will too when we have I/O
cgroups at a cgroup level, but the instances of such operations are
too many to accurately identify them all.

> 
> So what are you wanting to do, and why. Do you really need accounting
> madness?

I think Venki gave the answer in the posting

"There are usecases where reporting this time against task
or task groups or cgroups will be useful for user/administrator
in terms of resource planning and utilization charging"

I don't have any specific use cases, I was just reviewing the patchset
and trying to understand how to solve the problem.


-- 
	Three Cheers,
	Balbir

  parent reply	other threads:[~2010-08-24 12:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-19 23:57 [PATCH 0/4] Finer granularity and task/cgroup irq time accounting Venkatesh Pallipadi
2010-07-19 23:57 ` [PATCH 1/4] sched: Track and export per task [hard|soft]irq time Venkatesh Pallipadi
2010-07-19 23:57 ` [PATCH 2/4] x86: Add IRQ_TIME_ACCOUNTING, finer accounting of irq time to task Venkatesh Pallipadi
2010-07-19 23:57 ` [PATCH 3/4] sched: Generalize cpuacct usage tracking making it simpler to add new stats Venkatesh Pallipadi
2010-07-19 23:57 ` [PATCH 4/4] sched: Export irq times through cpuacct cgroup Venkatesh Pallipadi
2010-07-20  7:55 ` [PATCH 0/4] Finer granularity and task/cgroup irq time accounting Martin Schwidefsky
2010-07-20 16:55   ` Venkatesh Pallipadi
2010-07-22 11:12     ` Martin Schwidefsky
2010-07-23  2:12       ` Venkatesh Pallipadi
2010-08-24  7:51         ` Peter Zijlstra
2010-08-24  8:05           ` Balbir Singh
2010-08-24  9:09             ` Peter Zijlstra
2010-08-24 11:38               ` Balbir Singh
2010-08-24 11:49                 ` Peter Zijlstra
2010-08-24 11:53                 ` Peter Zijlstra
2010-08-24 12:06                   ` Martin Schwidefsky
2010-08-24 12:39                     ` Peter Zijlstra
2010-08-24 12:47                   ` Balbir Singh [this message]
2010-08-24 13:08                     ` Peter Zijlstra
2010-08-24 19:20                   ` Venkatesh Pallipadi
2010-08-24 20:39                     ` Peter Zijlstra
2010-08-25  2:02                       ` Venkatesh Pallipadi
2010-08-25  7:20                         ` Martin Schwidefsky
2010-09-08 11:12                         ` Peter Zijlstra
2010-08-24  8:14           ` Ingo Molnar
2010-08-24  8:49             ` Peter Zijlstra
2010-08-24  0:56 ` Venkatesh Pallipadi
2010-08-24  7:52   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100824124726.GQ4684@balbir.in.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=venki@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.