From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Arnd Bergmann <arnd@arndb.de>,
kvm-ppc@vger.kernel.org, Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Date: Thu, 21 Aug 2008 13:31:46 +0000 [thread overview]
Message-ID: <48AD6E42.6060406@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080820151848.69cb8f16@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Wed, 20 Aug 2008 14:06:51 -0500
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
>
>>>>> To be honest I unfortunately don't know how big the impact for
>>>>> non-virtualized systems is. I would like to test it, but without
>>>>> hardware performance counters on the core I have I'm not sure (yet)
>>>>> how
>>>>> to measure that in a good way - any suggestion welcome.
>>>>>
>>>> I don't see why we need performance counters. Can't we just compare any
>>>> bare metal benchmark results with the patch both applied and not?
>>>>
>>> Do you know of one that causes a large amount of
>>> local_irq_{disable,enable}s to be called?
>>>
>> I think *every* workload causes a large number of
>> local_irq_{disable,enable} calls... :)
>>
>
> Well, sure. I was just going for "test the change as specifically as
> possible." One could write a module that did X number of
> disable/enable pairs and reported the timebase at start and end to
> compare. X could even be a module parameter. Just to try and
> eliminate noise or whatever from the testing.
>
> /me shrugs.
>
> josh
>
yeah I thought of something like that too, because I expect the
difference to be very small.
Instead of a module I wanted to put this somewhere prior to the kernel
mounting root-fs to avoid interferences from whatever userspace is doing
(e.g. causing thousands of interrupts come back while the module
perform that test.).
Eventually we need a synthetic benchmark like that AND a check how it
affects a common system to be sure.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Arnd Bergmann <arnd@arndb.de>,
kvm-ppc@vger.kernel.org, Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Date: Thu, 21 Aug 2008 15:31:46 +0200 [thread overview]
Message-ID: <48AD6E42.6060406@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080820151848.69cb8f16@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Wed, 20 Aug 2008 14:06:51 -0500
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
>
>>>>> To be honest I unfortunately don't know how big the impact for
>>>>> non-virtualized systems is. I would like to test it, but without
>>>>> hardware performance counters on the core I have I'm not sure (yet)
>>>>> how
>>>>> to measure that in a good way - any suggestion welcome.
>>>>>
>>>> I don't see why we need performance counters. Can't we just compare any
>>>> bare metal benchmark results with the patch both applied and not?
>>>>
>>> Do you know of one that causes a large amount of
>>> local_irq_{disable,enable}s to be called?
>>>
>> I think *every* workload causes a large number of
>> local_irq_{disable,enable} calls... :)
>>
>
> Well, sure. I was just going for "test the change as specifically as
> possible." One could write a module that did X number of
> disable/enable pairs and reported the timebase at start and end to
> compare. X could even be a module parameter. Just to try and
> eliminate noise or whatever from the testing.
>
> /me shrugs.
>
> josh
>
yeah I thought of something like that too, because I expect the
difference to be very small.
Instead of a module I wanted to put this somewhere prior to the kernel
mounting root-fs to avoid interferences from whatever userspace is doing
(e.g. causing thousands of interrupts come back while the module
perform that test.).
Eventually we need a synthetic benchmark like that AND a check how it
affects a common system to be sure.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
next prev parent reply other threads:[~2008-08-21 13:31 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-19 10:36 [PATCH 0/4][RFC] kvmppc: paravirtualization interface - guest part v2 ehrhardt
2008-08-19 10:36 ` ehrhardt
2008-08-19 10:36 ` [PATCH 1/4] kvmppc: read device tree hypervisor node infrastructure ehrhardt
2008-08-19 10:36 ` ehrhardt
2008-08-19 11:52 ` [PATCH 1/4] kvmppc: read device tree hypervisor node Josh Boyer
2008-08-19 11:52 ` [PATCH 1/4] kvmppc: read device tree hypervisor node infrastructure Josh Boyer
2008-08-19 11:56 ` [PATCH 1/4] kvmppc: read device tree hypervisor node Josh Boyer
2008-08-19 11:56 ` [PATCH 1/4] kvmppc: read device tree hypervisor node infrastructure Josh Boyer
2008-08-19 10:36 ` [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part ehrhardt
2008-08-19 10:36 ` ehrhardt
2008-08-19 11:28 ` Arnd Bergmann
2008-08-19 11:28 ` Arnd Bergmann
2008-08-20 12:41 ` Christian Ehrhardt
2008-08-20 12:41 ` Christian Ehrhardt
2008-08-21 22:25 ` Hollis Blanchard
2008-08-21 22:25 ` Hollis Blanchard
2008-08-22 10:38 ` Kumar Gala
2008-08-22 10:38 ` Kumar Gala
2008-08-22 14:00 ` Hollis Blanchard
2008-08-22 14:00 ` Hollis Blanchard
2008-08-19 10:36 ` [PATCH 3/4] kvmppc: magic page paravirtualization " ehrhardt
2008-08-19 10:36 ` ehrhardt
2008-08-20 2:29 ` Tony Breeds
2008-08-20 2:29 ` Tony Breeds
2008-08-19 10:36 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization ehrhardt
2008-08-19 10:36 ` ehrhardt
2008-08-19 11:42 ` Arnd Bergmann
2008-08-19 11:42 ` Arnd Bergmann
2008-08-20 12:53 ` Christian Ehrhardt
2008-08-20 12:53 ` Christian Ehrhardt
2008-08-20 18:30 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest Hollis Blanchard
2008-08-20 18:30 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization Hollis Blanchard
2008-08-20 18:52 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest Josh Boyer
2008-08-20 18:52 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization Josh Boyer
2008-08-20 19:06 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest Hollis Blanchard
2008-08-20 19:06 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization Hollis Blanchard
2008-08-20 19:18 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest Josh Boyer
2008-08-20 19:18 ` [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization Josh Boyer
2008-08-21 13:31 ` Christian Ehrhardt [this message]
2008-08-21 13:31 ` Christian Ehrhardt
2008-08-21 13:41 ` Kumar Gala
2008-08-21 13:41 ` Kumar Gala
2008-08-21 14:13 ` Christian Ehrhardt
2008-08-21 14:13 ` Christian Ehrhardt
2008-08-21 14:21 ` Kumar Gala
2008-08-21 14:21 ` Kumar Gala
2008-08-21 16:16 ` Scott Wood
2008-08-21 16:16 ` Scott Wood
2008-08-22 8:08 ` Christian Ehrhardt
2008-08-22 8:08 ` Christian Ehrhardt
2008-08-22 8:17 ` Kumar Gala
2008-08-22 8:17 ` Kumar Gala
2008-08-22 13:56 ` Jimi Xenidis
2008-08-22 13:56 ` Jimi Xenidis
2008-08-22 15:49 ` Scott Wood
2008-08-22 15:49 ` Scott Wood
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=48AD6E42.6060406@linux.vnet.ibm.com \
--to=ehrhardt@linux.vnet.ibm.com \
--cc=arnd@arndb.de \
--cc=hollisb@us.ibm.com \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.