[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090115180052.GG29283@parisc-linux.org>
Date: Thu, 15 Jan 2009 11:00:53 -0700
From: Matthew Wilcox <matthew@....cx>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>,
"Wilcox, Matthew R" <matthew.r.wilcox@...el.com>,
chinang.ma@...el.com, linux-kernel@...r.kernel.org,
sharad.c.tripathi@...el.com, arjan@...ux.intel.com,
andi.kleen@...el.com, suresh.b.siddha@...el.com,
harita.chilukuri@...el.com, douglas.w.styner@...el.com,
peter.xihong.wang@...el.com, hubert.nueckel@...el.com,
chris.mason@...cle.com, srostedt@...hat.com,
linux-scsi@...r.kernel.org,
Andrew Vasquez <andrew.vasquez@...gic.com>,
Anirban Chakraborty <anirban.chakraborty@...gic.com>
Subject: Re: Mainline kernel OLTP performance update
On Thu, Jan 15, 2009 at 09:44:42AM -0800, Andrew Morton wrote:
> > Me too. Anecdotally, I haven't noticed this in my lab machines, but
> > what I have noticed is on someone else's laptop (a hyperthreaded atom)
> > that I was trying to demo powertop on was that IPI reschedule interrupts
> > seem to be out of control ... they were ticking over at a really high
> > rate and preventing the CPU from spending much time in the low C and P
> > states. To me this implicates some scheduler problem since that's the
> > primary producer of IPI reschedules ... I think it wouldn't be a
> > significant extrapolation to predict that the scheduler might be the
> > cause of the above problem as well.
> >
>
> Good point.
>
> The context switch rate actually went down a bit.
>
> I wonder if the Intel test people have records of /proc/interrupts for
> the various kernel versions.
I think Chinang does, but he's out of office today. He did say in an
earlier reply:
> I took a quick look at the interrupts figure between 2.6.24 and 2.6.27.
> i/o interuputs is slightly down in 2.6.27 (due to reduce throughput).
> But both NMI and reschedule interrupt increased. Reschedule interrupts
> is 2x of 2.6.24.
So if the reschedule interrupt is happening twice as often, and the
context switch rate is basically unchanged, I guess that means the
scheduler is doing a lot more work to get approximately the same
results. And that seems like a bad thing.
Again, it's worth bearing in mind that these are all RT tasks, so the
underlying problem may be very different from the one that both James and
I have observed with an Atom laptop running predominantly non-RT tasks.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
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