From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Michael Abbott <michael@araneidae.co.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jan Engelhardt <jengelh@medozas.de>
Subject: Re: [GIT PULL] cputime patch for 2.6.30-rc6
Date: Wed, 20 May 2009 10:09:12 +0200 [thread overview]
Message-ID: <20090520100912.4f9c2037@skybase> (raw)
In-Reply-To: <1242725488.26820.485.camel@twins>
On Tue, 19 May 2009 11:31:28 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2009-05-19 at 11:00 +0200, Martin Schwidefsky wrote:
> > I don't see a problem here. In an idle multiple cpu system there IS
> > more idle time than elapsed time. What would makes sense is to compare
> > elapsed time * #cpus with the idle time. But then there is cpu hotplug
> > which forces you to look at the delta of two measuring points where the
> > number of cpus did not change.
>
> Sure, this one case isn't that bad, esp. as you note its about idle
> time. However, see for example /proc/stat and fs/proc/stat.c:
>
> for_each_possible_cpu(i) {
> user = cputime64_add(user, kstat_cpu(i).cpustat.user);
> nice = cputime64_add(nice, kstat_cpu(i).cpustat.nice);
> system = cputime64_add(system, kstat_cpu(i).cpustat.system);
> idle = cputime64_add(idle, kstat_cpu(i).cpustat.idle);
> idle = cputime64_add(idle, arch_idle_time(i));
> iowait = cputime64_add(iowait, kstat_cpu(i).cpustat.iowait);
> irq = cputime64_add(irq, kstat_cpu(i).cpustat.irq);
> softirq = cputime64_add(softirq, kstat_cpu(i).cpustat.softirq);
> steal = cputime64_add(steal, kstat_cpu(i).cpustat.steal);
> guest = cputime64_add(guest, kstat_cpu(i).cpustat.guest);
> for_each_irq_nr(j) {
> sum += kstat_irqs_cpu(j, i);
> }
> sum += arch_irq_stat_cpu(i);
> }
>
> If that isn't a problem on a large machine, then I don't know what is.
Well, we better distinguish between the semantical problem and the
performance consideration, no? One thing is what the proc field is
supposed to contain, the other is how fast you can do it.
I have been refering to the semantical problem, but your point with the
performance is very valid as well. So
1) are we agreed that the second field of /proc/uptime should contain
the aggregate idle time of all cpus?
2) I agree that an endless loop of 'cat /proc/uptime' or
'cat /proc/stat' can have negative performance impact on a system with
many cpus. One way to deal with it would be to restrict access to the
interface. I do not like that idea to much. Another way would be to
limit the number of for_each_possible_cpu loops per second. Create
global variables that contain the aggregate values for the different
fields. If the last update has been too recent (e.g. less than 0.1
seconds ago), just print the old values again.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2009-05-20 8:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 14:09 [GIT PULL] cputime patch for 2.6.30-rc6 Martin Schwidefsky
2009-05-18 15:24 ` Peter Zijlstra
2009-05-18 16:28 ` Michael Abbott
2009-05-19 9:00 ` Martin Schwidefsky
2009-05-19 9:31 ` Peter Zijlstra
2009-05-20 8:09 ` Martin Schwidefsky [this message]
2009-05-20 8:19 ` Peter Zijlstra
2009-05-20 8:44 ` Michael Abbott
2009-05-25 11:06 ` Martin Schwidefsky
2009-05-19 8:49 ` Martin Schwidefsky
2009-05-19 9:00 ` Peter Zijlstra
2009-05-25 10:50 ` Martin Schwidefsky
2009-05-25 11:09 ` Peter Zijlstra
2009-05-25 11:24 ` Jan Engelhardt
2009-05-25 11:35 ` Martin Schwidefsky
2009-05-19 13:32 ` Jan Engelhardt
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=20090520100912.4f9c2037@skybase \
--to=schwidefsky@de.ibm.com \
--cc=jengelh@medozas.de \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@araneidae.co.uk \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
/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