From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@elte.hu>, linux-kernel@vger.kernel.org
Subject: Re: Scheduler regression: Too frequent timer interrupts(?)
Date: Fri, 17 Apr 2009 16:16:16 +0200 [thread overview]
Message-ID: <1239977776.23397.4590.camel@laptop> (raw)
In-Reply-To: <alpine.DEB.1.10.0904170941020.11877@qirst.com>
On Fri, 2009-04-17 at 09:42 -0400, Christoph Lameter wrote:
> On Fri, 17 Apr 2009, Peter Zijlstra wrote:
>
> > This has never been true afaikt, as long as we have a task running, we
> > take the interrupt, I just looked at the .22 code and that certainly
> > expects the scheduler_tick() to be called when there is a running
> > process.
> >
> > Also, look at /proc/interrupts if you want to determine interrupt
> > frequency.
>
> I am mainly interested in limited the number and length of cpu holdoffs.
>
> If the timer interrupt is always taken then it must take less than 1 usec
> in certain versions of the kernel in order to not show up in the
> statistics gathered.
Such a test as you had is pretty useless for anything.
If you want to measure something I'd suggest making a histogram of tsc
values in 10ns buckets or something, and seeing if there are a few
predominant spikes above the noise.
With something like that you could say, the jiffy tick went from 0.8+-.1
to 1.1+-.1 us or somesuch.
After that, you could possibly use oprofile or readprofile or
perf-counters to get an idea where the time is spend. I did a quick
profile on one of my machines, and about half the kernel time spend in a
while(1) loop comes from __do_softirq().
Really, I should not have to tell you this...
next prev parent reply other threads:[~2009-04-17 14:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 19:53 Scheduler regression: Too frequent timer interrupts(?) Christoph Lameter
2009-04-17 7:00 ` Peter Zijlstra
2009-04-17 13:42 ` Christoph Lameter
2009-04-17 14:16 ` Peter Zijlstra [this message]
2009-04-17 14:29 ` Christoph Lameter
2009-04-17 14:51 ` Peter Zijlstra
2009-04-17 15:04 ` Christoph Lameter
2009-04-17 15:28 ` Peter Zijlstra
2009-04-23 4:42 ` Pavel Machek
2009-04-28 21:02 ` Christoph Lameter
2009-04-28 21:23 ` Peter Zijlstra
2009-04-28 21:21 ` Christoph Lameter
2009-04-17 15:35 ` Ingo Molnar
2009-04-17 15:55 ` Christoph Lameter
2009-04-17 16:23 ` Peter Zijlstra
2009-04-17 16:33 ` Christoph Lameter
2009-04-17 16:49 ` Ingo Molnar
2009-04-17 17:19 ` Chris Friesen
2009-04-17 17:45 ` Christoph Lameter
2009-04-17 18:11 ` Peter Zijlstra
2009-04-17 18:20 ` Christoph Lameter
2009-04-17 18:58 ` Peter Zijlstra
2009-04-17 20:34 ` Christoph Lameter
2009-04-17 20:53 ` Peter Zijlstra
2009-04-17 23:24 ` Chris Friesen
2009-04-18 7:35 ` Ingo Molnar
2009-04-18 7:59 ` Andi Kleen
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=1239977776.23397.4590.camel@laptop \
--to=peterz@infradead.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.