public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Alex Nixon (Intern)" <Alex.Nixon@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: Re: Large increase in context switch rate
Date: Thu, 17 Jul 2008 11:17:30 +0200	[thread overview]
Message-ID: <1216286250.5232.67.camel@twins> (raw)
In-Reply-To: <487E43D9.7080703@goop.org>

On Wed, 2008-07-16 at 11:54 -0700, Jeremy Fitzhardinge wrote:
> Hi Ingo,
> 
> We have Alex Nixon doing some profiling of Xen kernels, comparing 
> current pvops Xen and native with the last "official" Xen kernel 
> 2.6.18.8-xen.
> 
> One obvious difference is that the kernbench context switch rate is way 
> up, from about 30k to 110k.  Also, the user time went up from about 375s 
> to 390s - and that's comparing pvops native to 2.6.18.8-xen (pvops Xen 
> was more or less identical).
> 
> I wonder if the user time increase is related to the context switch 
> rate, because the actual context switch time itself is accounted to the 
> process, or because of secondary things like cache and tlb misses.  Or 
> perhaps the new scheduler accounts for things differently?
> 
> Anyway, I'm wondering:
> 
>     * is the increased context switch rate expected?
>     * what tunables are there so we can try and make them have
>       comparable context switch rates?
> 
> This is an issue because the Xen/pvops kernel is showing a fairly large 
> overall performance regression, and the context switches a specifically 
> slow compared to the old Xen kernel, and the high switch rate is 
> presumably compounding the problem.  It would be nice to have some knobs 
> to turn to see what the underlying performance characteristics are.

Is this specific to Xen?, as a native kernel doesn't do more than ~3k
cs/s with make -j3 on my dual core.




  reply	other threads:[~2008-07-17  9:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16 18:54 Large increase in context switch rate Jeremy Fitzhardinge
2008-07-17  9:17 ` Peter Zijlstra [this message]
2008-07-17 15:02   ` Jeremy Fitzhardinge
2008-07-17 15:14     ` Alex Nixon (Intern)
2008-07-17 15:21       ` Peter Zijlstra
2008-07-17 15:45       ` Jeremy Fitzhardinge
2008-07-17 16:04         ` Alex Nixon (Intern)
2008-07-17 16:11           ` Jeremy Fitzhardinge
2008-07-17 21:43             ` Andi Kleen
2008-07-18 17:00               ` Alex Nixon (Intern)
2008-07-23  9:34               ` Alex Nixon (Intern)
2008-07-23 13:54                 ` Andi Kleen
2008-07-24  1:26                 ` Nick Piggin
2008-07-25 11:31                   ` Alex Nixon
2008-07-25 11:39                     ` Peter Zijlstra
2008-07-25 14:54                     ` Jeremy Fitzhardinge

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=1216286250.5232.67.camel@twins \
    --to=peterz@infradead.org \
    --cc=Alex.Nixon@eu.citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=jeremy@goop.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox