Rusty Russell wrote:
> You'll still have the damage inflicted on gcc's optimizer, though.
Well, I could remove the clobbers for PVOP_CALL[0-2] and add the
appropriate push/pops, and put similar push/pop wrappers around all the
called functions. But it doesn't make it any prettier.
J
-
To uns
On Wed, 2007-04-04 at 17:56 +0200, Andi Kleen wrote:
> On Wednesday 04 April 2007 17:45:44 Jeremy Fitzhardinge wrote:
> > Andi Kleen wrote:
> > > Why is there a difference for null syscall? I had assumed we patched all
> > > the
> > > fast path cases relevant there. Do you have an idea where it c
Ingo Molnar wrote:
> sure. i simply took the middle numbers. But there's definitely a 'few
> percents' trend in the numbers.
>
Yep. I guess the thing that coloured my summary is that I found overhead
of unpatched paravirt_ops calls surprisingly small. I was really
expecting more like ~10% hit
Andi Kleen wrote:
> I was talking about the patched case. It seemed to be a little slower
> too, but in theory it shouldn't have been, no?
Oh, the .25 vs .26? That's definitely noise; on other runs I see no
difference:
paravirt, patched, busy machine
ezr Linux 2.6.21- 1000 0.25 0.52 31.3
On Wednesday 04 April 2007 17:45:44 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Why is there a difference for null syscall? I had assumed we patched all
> > the
> > fast path cases relevant there. Do you have an idea where it comes from?
>
> Sure. There's indirect calls for things like s
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > the main metric we are interested in is the overhead for people who just
> > want to run the non-patched native kernel that has CONFIG_PARAVIRT
> > enabled (99%+ of the users at the moment), so the delta is:
> >
> > null
Andi Kleen wrote:
> Why is there a difference for null syscall? I had assumed we patched all the
> fast path cases relevant there. Do you have an idea where it comes from?
Sure. There's indirect calls for things like sti/cli/iret. It goes
back to native speed when you patch the real instruction
Ingo Molnar wrote:
> the main metric we are interested in is the overhead for people who just
> want to run the non-patched native kernel that has CONFIG_PARAVIRT
> enabled (99%+ of the users at the moment), so the delta is:
>
> null: +12.0%
> null IO:+7.5%
> stat:
> > paravirt, patching
> > ezr Linux 2.6.21- 1000 0.25 0.53 31.8 34.4 10.1 1.04 5.44 730. 1583
> > 4600
> > ezr Linux 2.6.21- 1000 0.26 0.55 32.1 35.2 13.3 1.03 5.48 748. 1589
> > 4606
> > ezr Linux 2.6.21- 1000 0.26 0.54 32.0 34.9 14.1 1.04 5.43 752. 1606
> > 4647
>
> i gues
On Wednesday 04 April 2007 11:25:57 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > What do the benchmarks say with CONFIG_PARAVIRT on native hardware
> > compared to !CONFIG_PARAVIRT. e.g. does lmbench suffer?
>
> Barely. There's a slight hit for not using patching, and patching is
> almost
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > What do the benchmarks say with CONFIG_PARAVIRT on native hardware
> > compared to !CONFIG_PARAVIRT. e.g. does lmbench suffer?
>
> Barely. There's a slight hit for not using patching, and patching is
> almost identical to native performance
Andi Kleen wrote:
> What do the benchmarks say with CONFIG_PARAVIRT on native hardware
> compared to !CONFIG_PARAVIRT. e.g. does lmbench suffer?
Barely. There's a slight hit for not using patching, and patching is
almost identical to native performance. The most noticeable difference
is in the
Andi Kleen wrote:
> What do the benchmarks say with CONFIG_PARAVIRT on native hardware
> compared to !CONFIG_PARAVIRT. e.g. does lmbench suffer?
>
I haven't measured it, but I'll do some experiments.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Mon, 2007-04-02 at 08:12 +0200, Andi Kleen wrote:
> On Monday 02 April 2007 07:56, Jeremy Fitzhardinge wrote:
> > Add a set of accessors to pack, unpack and modify page table entries
> > (at all levels). This allows a paravirt implementation to control the
> > contents of pgd/pmd/pte entries.
On Monday 02 April 2007 07:56, Jeremy Fitzhardinge wrote:
> Add a set of accessors to pack, unpack and modify page table entries
> (at all levels). This allows a paravirt implementation to control the
> contents of pgd/pmd/pte entries. For example, Xen uses this to
> convert the (pseudo-)physical
Add a set of accessors to pack, unpack and modify page table entries
(at all levels). This allows a paravirt implementation to control the
contents of pgd/pmd/pte entries. For example, Xen uses this to
convert the (pseudo-)physical address into a machine address when
populating a pagetable entry,
16 matches
Mail list logo
