On Fri, 2007-03-02 at 16:16 -0800, Jeremy Fitzhardinge wrote:
>
> Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
> hardware will have negligible performance hit compared to running a
> non-paravirt kernel.
>
> J
It turned out that VDSO was turned off by CONFIG_PARAVIRT
Tim Chen wrote:
> It turned out that VDSO was turned off by CONFIG_PARAVIRT option,
> causing the system call to use inefficient int 0x80 which led to the
> increase system_call time I was seeing. I noted that Ingo has caught
> this problem and proposed a patch to correct this issue in another
On Fri, 2007-03-02 at 16:16 -0800, Jeremy Fitzhardinge wrote:
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to running a
non-paravirt kernel.
J
It turned out that VDSO was turned off by CONFIG_PARAVIRT
Tim Chen wrote:
It turned out that VDSO was turned off by CONFIG_PARAVIRT option,
causing the system call to use inefficient int 0x80 which led to the
increase system_call time I was seeing. I noted that Ingo has caught
this problem and proposed a patch to correct this issue in another mail
Jeremy Fitzhardinge wrote:
Tim Chen wrote:
I also hope that the performance can be recovered as this option could
enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to
Tim Chen wrote:
> I also hope that the performance can be recovered as this option could
> enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to running a
non-paravirt kernel.
On Fri, 2007-03-02 at 13:54 -0800, Jeremy Fitzhardinge wrote:
> [ I assume you're talking about running on native hardware. ]
>
That's correct.
> I haven't done any detailed measurements on what effect this will have,
> but it does bring the actual executed instruction stream much closer to
>
Tim Chen wrote:
> With CONFIG_PARAVIRT turned on, I've found that time invoking
> system_call jumped up quite a lot. Using TCP streaming test as a
> workload and running on 32-bit 2.6.20 kernel, system_call goes up from
> 0.00025% all the way to 1.6% in the oprofile data. There is a drop of
>
With CONFIG_PARAVIRT turned on, I've found that time invoking
system_call jumped up quite a lot. Using TCP streaming test as a
workload and running on 32-bit 2.6.20 kernel, system_call goes up from
0.00025% all the way to 1.6% in the oprofile data. There is a drop of
about 4% in overall
With CONFIG_PARAVIRT turned on, I've found that time invoking
system_call jumped up quite a lot. Using TCP streaming test as a
workload and running on 32-bit 2.6.20 kernel, system_call goes up from
0.00025% all the way to 1.6% in the oprofile data. There is a drop of
about 4% in overall
Tim Chen wrote:
With CONFIG_PARAVIRT turned on, I've found that time invoking
system_call jumped up quite a lot. Using TCP streaming test as a
workload and running on 32-bit 2.6.20 kernel, system_call goes up from
0.00025% all the way to 1.6% in the oprofile data. There is a drop of
about
On Fri, 2007-03-02 at 13:54 -0800, Jeremy Fitzhardinge wrote:
[ I assume you're talking about running on native hardware. ]
That's correct.
I haven't done any detailed measurements on what effect this will have,
but it does bring the actual executed instruction stream much closer to
the
Tim Chen wrote:
I also hope that the performance can be recovered as this option could
enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to running a
non-paravirt kernel.
J
Jeremy Fitzhardinge wrote:
Tim Chen wrote:
I also hope that the performance can be recovered as this option could
enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to
14 matches
Mail list logo
