[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1237298686.7867.17.camel@twins>
Date: Tue, 17 Mar 2009 15:04:46 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: balbir@...ux.vnet.ibm.com
Cc: Bharata B Rao <bharata@...ux.vnet.ibm.com>,
Li Zefan <lizf@...fujitsu.com>, linux-kernel@...r.kernel.org,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Paul Menage <menage@...gle.com>, Ingo Molnar <mingo@...e.hu>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [PATCH -tip] cpuacct: Make cpuacct hierarchy walk in
cpuacct_charge() safe when rcupreempt is used.
On Tue, 2009-03-17 at 19:29 +0530, Balbir Singh wrote:
> * Peter Zijlstra <a.p.zijlstra@...llo.nl> [2009-03-17 14:26:01]:
>
> > On Tue, 2009-03-17 at 18:42 +0530, Balbir Singh wrote:
> >
> > > I'd like to get the patches in -tip and see the results, I would
> > > recommend using percpu_counter_sum() while reading the data as an
> > > enhancement to this patch. If user space does not overwhelm with a lot
> > > of reads, sum would work out better.
> >
> > You trust userspace? I'd rather not.
> >
>
> Fair enough.. A badly written application monitor can frequently read
> this data and cause horrible performance issues. On the other hand
> large number of CPUs can make the lag even worse. Is it time yet for
> percpu_counter batch numbers? I've tested this patch and the results
> were not badly off the mark.
I'd rather err on the side of caution here, you might get some crazy
folks depending on it and then expecting us to maintain it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists