public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Balaji Rao <balajirrao@gmail.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, containers@lists.osdl.org,
	menage@google.com, balbir@in.ibm.com,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: Re: [RFC][-mm] [1/2] Simple stats for cpu resource controller
Date: Thu, 10 Apr 2008 18:25:11 +0200	[thread overview]
Message-ID: <1207844711.7074.8.camel@twins> (raw)
In-Reply-To: <200804102140.00078.balajirrao@gmail.com>

On Thu, 2008-04-10 at 21:39 +0530, Balaji Rao wrote:
> On Monday 07 April 2008 06:54:53 pm Peter Zijlstra wrote:
> > On Sun, 2008-04-06 at 02:01 +0530, Balaji Rao wrote:
> > 
> > > > > +static s64 cpu_cgroup_read_stat(struct cpu_cgroup_stat *stat,
> > > > > +		enum cpu_cgroup_stat_index idx)
> > > > > +{
> > > > > +	int cpu;
> > > > > +	s64 ret = 0;
> > > > > +	unsigned long flags;
> > > > 
> > > > > +
> > > > > +	local_irq_save(flags);
> > > > 
> > > > I am just wondering. Is local_irq_save() enough?
> > > > 
> > > Hmmm.. You are right.This does not prevent concurrent updates on other 
> CPUs 
> > > from crossing a 32bit boundary. Am not sure how to do this in a safe way. 
> I 
> > > can only think of using atomic64_t now..
> > > 
> > > > > +	for_each_possible_cpu(cpu)
> > > > > +		ret += stat->cpustat[cpu].count[idx];
> > > > > +	local_irq_restore(flags);
> > > > > +
> > > > > +	return ret;
> > > > > +}
> > > > > +
> > 
> > So many stats to steal code from,.. but you didn't :-(
> > 
> > Look at mm/vmstat.c, that is a rather complete example.
> > 
> > The trick to solving the above is to use per cpu deltas instead, the
> > deltas can be machine word size and are thus always read in an atomic
> > manner (provided they are also naturally aligned).
> > 
> > 
> Hi Peter,
> 
> This wont work for time based statistics. At nsec granularity, a word can hold 
> a time value of up to ~4s. 

4 seconds is plenty for a delta, most increments are in the ms range.

> I propose to solve this problem by using a lock to protect the statistics, but 
> only on 32bit architectures.
> 
> I'm not sure how good a solution this is, but that's the best I can think of 
> ATM. 

Not needed, keep per cpu word deltas and fold into a global u64 counter
while holding a lock.



  reply	other threads:[~2008-04-10 16:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-05 18:09 [RFC][-mm] [1/2] Simple stats for cpu resource controller Balaji Rao
2008-04-05 18:56 ` Dhaval Giani
2008-04-05 19:09   ` Balaji Rao
2008-04-05 19:40 ` Dhaval Giani
2008-04-05 20:31   ` Balaji Rao
2008-04-05 20:59     ` Dhaval Giani
2008-04-05 21:21       ` Balaji Rao
2008-04-06  5:12         ` Balbir Singh
2008-04-07 13:24     ` Peter Zijlstra
2008-04-10 16:09       ` Balaji Rao
2008-04-10 16:25         ` Peter Zijlstra [this message]
2008-05-01 17:41           ` [RFC][-mm] Simple stats for cpu resource controller v3 Balaji Rao
2008-05-01 21:00             ` Andrew Morton
2008-05-02 19:40               ` Balaji Rao
2008-05-02 19:53                 ` Andrew Morton
2008-05-02 22:47                   ` Balaji Rao
2008-05-02 23:04                     ` Andrew Morton
     [not found] ` <200805030457.54073.balajirrao@gmail.com>
     [not found]   ` <20080502164133.9025a02c.akpm@linux-foundation.org>
2008-05-02 23:56     ` Balaji Rao
2008-05-03  0:19       ` Andrew Morton
2008-05-11 20:18         ` [RFC][-mm] Simple stats for cpu resource controller v4 Balaji Rao
2008-05-12  2:54           ` Li Zefan
2008-05-12  5:41             ` Balaji Rao
2008-05-12 23:48           ` Andrew Morton
2008-05-13  3:30             ` Balaji Rao
  -- strict thread matches above, loose matches on Subject: below --
2008-03-26 18:18 [RFC][-mm] [1/2] Simple stats for cpu resource controller Balaji Rao
2008-03-26 19:00 ` Paul Menage
2008-03-26 19:58 ` Peter Zijlstra
2008-03-28 10:02   ` Balaji Rao
2008-03-28 10:17     ` 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=1207844711.7074.8.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=balajirrao@gmail.com \
    --cc=balbir@in.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=vatsa@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox