[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CC07784.4090805@digium.com>
Date: Thu, 21 Oct 2010 12:25:24 -0500
From: Shaun Ruffell <sruffell@...ium.com>
To: Venkatesh Pallipadi <venki@...gle.com>
CC: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-kernel@...r.kernel.org, Paul Turner <pjt@...gle.com>,
Eric Dumazet <eric.dumazet@...il.com>,
Yong Zhang <yong.zhang0@...il.com>
Subject: Re: [PATCH 0/5] Proper kernel irq time reporting -v0
On 10/20/2010 05:48 PM, Venkatesh Pallipadi wrote:
> This is part 2 of
> "Proper kernel irq time accounting -v4"
> http://lkml.indiana.edu/hypermail//linux/kernel/1010.0/01175.html
>
> and applies over those changes.
>
I applied both sets on top of 2.6.36 and tested on x86 32-bit and 64-bit
machines with some telephony cards that interrupt at a 1000Hz rate. The
time reported in top matched the expected value as measured with the
function graph tracer. i.e, if /sys/kernel/debug/tracing/trace
indicated that the interrupt handler was averaging 13us, then top was
reporting 1.3% CPU time. I changed the smp_affinity and the "hi" time
moved around as I would have expected. I also scheduled work items on
all the CPUs that just disable interrupt and spin for a selectable
period. Scheduling 100ms of non-interruptible delay at 1 second
intervals resulted in 10% time in "hi" as expected.
Hopefully I can check it out on a Powermac G3 B&W next week sometime,
but FWIW:
Tested-by: Shaun Ruffell <sruffell@...ium.com>
--
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