Messages in this thread | | | Date | Thu, 30 Apr 2009 18:10:45 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v2] cpuacct: VIRT_CPU_ACCOUNTING don't prevent percpu cputime count |
| |
On Thu, 30 Apr 2009 15:11:15 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > Changelog: > since v1 > - use percpu_counter_sum() instead percpu_counter_read() > > > ------------------------------------- > Subject: [PATCH v2] cpuacct: VIRT_CPU_ACCOUNTING don't prevent percpu cputime count > > cpuacct_update_stats() is called at every tick updating. and it use percpu_counter > for avoiding performance degression. > > For archs which define VIRT_CPU_ACCOUNTING, every tick would result > in >1000 units of cputime updates and since this is much much greater > than percpu_batch_counter, we end up taking spinlock on every tick. > > This patch change batch rule. now, any cpu can store "percpu_counter_bach * jiffies" > cputime in per-cpu cache. > it mean this patch don't have behavior change if VIRT_CPU_ACCOUNTING=n.
Does this actually matter?
If we're calling cpuacct_update_stats() with large values of `cputime' then presumably we're also calling cpuacct_update_stats() at a low frequency, so the common lock-taking won't cause performance problems?
| |