[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200807241126.48364.nickpiggin@yahoo.com.au>
Date: Thu, 24 Jul 2008 11:26:48 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: "Alex Nixon (Intern)" <Alex.Nixon@...citrix.com>
Cc: "Andi Kleen" <andi@...stfloor.org>,
"Jeremy Fitzhardinge" <jeremy@...p.org>,
"Peter Zijlstra" <peterz@...radead.org>,
"Ingo Molnar" <mingo@...e.hu>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Ian Campbell" <Ian.Campbell@...citrix.com>,
"Theodore Ts'o" <tytso@....edu>
Subject: Re: Large increase in context switch rate
On Wednesday 23 July 2008 19:34, Alex Nixon (Intern) wrote:
> > -----Original Message-----
> > From: Andi Kleen [mailto:andi@...stfloor.org]
> > Sent: 17 July 2008 22:43
> > To: Jeremy Fitzhardinge
> > Cc: Alex Nixon (Intern); Peter Zijlstra; Ingo Molnar; Linux
> > Kernel Mailing List; Ian Campbell
> > Subject: Re: Large increase in context switch rate
> >
> > Jeremy Fitzhardinge <jeremy@...p.org> writes:
> > > OK, but that still doesn't account for the relatively large increase
> > > from 2.6.18 -> 2.6.26. You're using HZ=100 in both cases,
> >
> > I presume.
> >
> > > The other variable is NOHZ and highres timers. You could
> >
> > try turning
> >
> > > those off in 2.6.26. Also, CONFIG_PREEMPT could well make a
> > > difference. 2.6.18-xen doesn't support CONFIG_PREEMPT at all, but
> > > pvops(-xen) does.
> >
> > If it's that easily reproducible you could just bisect it?
> >
> > -Andi
>
> I've bisected down to commit ba52de123d454b57369f291348266d86f4b35070 -
> [PATCH] inode-diet. Before that kernbench consistently reports about
> 35k context switches (total), and after that commit about 53k. The
> benchmarks are being run on a tmpfs. I've verified the results on a
> different machine, albeit with an almost identical setup (the same
> kernels and debian distro, kernbench version, and benchmarking a build
> of the same source).
>
> Seems to be a mystery why that patch is (seemingly) the culprit...anyone
> have any ideas? Maybe there's some other variable I'm not keeping
> constant?
Weird. It could possibly be triggering some different userspace behaviour
if blocksize reporting has changed anywhere. strace might help there.
Interesting if you could post the top results of profile=schedule for
a kernel with and without the patch.
--
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