Re: [Fedora-xen] Xen/Linux 3.4.2 performance

Re: [Fedora-xen] Xen/Linux 3.4.2 performance

[Konrad Rzeszutek Wilk]

On Tue, Jul 03, 2012 at 08:59:34AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 03, 2012 at 07:16:04AM -0500, W. Michael Petullo wrote:
> > >> We have seen a significant reduction in performance in our research DomU
> > >> OS kernel when running on Fedora 16 with Linux 3.4.2 vs. 3.3.7. We run
> > > a series of benchmarks which are DomU-kernel-space-CPU-heavy; many of
> > >> these run 10x slower when using the 3.4.2 Linux kernel as Dom0.
> > >> 
> > >> This is a little surprising---we've been tracking the Fedora kernels for
> > >> a long time with no problem like this. Did anyone else notice any changes?
> > >> 
> > > 
> > > Just to verify.. both the 3.3.7 and 3.4.2 Linux kernel are 'release' builds? 
> > > and not debug-versions from rawhide? 
> > 
> > Yes, they are the Fedora 16 release builds.
> 
> The commits that went in (3.4) were:
...
> So one thing that you might be hitting is that now the CPU freq driver is
> uploading the data to the hypervisor - the hypervisor might be doing
> power-save stuff instead of concentrating on giving your raw performance.
> 
> So can you start with 'cpufreq=verbose,performance' on your hypervisor line.

Michael openned a bug and on it we found that the xen-acpi-processor.off=1
would solve the performance problem. What that does is to not upload C-states
and P-states information to the hypervisor. So I pulled up an AMD box
and found that the problem is only if hypervisor enters C-2 states. If
I do 'xenpm set-max-cstate 1' it gets back to working nicely.

Wei, any ideas? This is with Xen 4.1


--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Re: [Fedora-xen] Xen/Linux 3.4.2 performance

[Jan Beulich]

>>> On 02.08.12 at 18:51, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> Michael openned a bug and on it we found that the xen-acpi-processor.off=1
> would solve the performance problem. What that does is to not upload C-states
> and P-states information to the hypervisor. So I pulled up an AMD box
> and found that the problem is only if hypervisor enters C-2 states. If
> I do 'xenpm set-max-cstate 1' it gets back to working nicely.
> 
> Wei, any ideas? This is with Xen 4.1

Is that 4.1 you're using lacking a backport of -unstable
25195:a06e6cdeafe3 (4.1-testing 23298:435493696053)?

Jan