linux-kernel - RE: Large increase in context switch rate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0E902970173AF84089673FA54B7FE78A329073@lonpexch01.citrite.net>
Date:	Wed, 23 Jul 2008 10:34:10 +0100
From:	"Alex Nixon (Intern)" <Alex.Nixon@...citrix.com>
To:	"Andi Kleen" <andi@...stfloor.org>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"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

 

> -----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?

- Alex
--
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/