|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [Patch 0 of 2]: PV-domain SMP performance
Keir Fraser wrote:
> On 17/12/2008 12:21, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxxxxxxx>
> wrote:
>
>> This result was achieved by avoiding descheduling of a vcpu only when irqs
>> are blocked. Even better results might be possible with some fine tuning
>> (e.g. instrumenting bh_enable/bh_disable).
>> I think system time has dropped remarkably!
>
> It's nice, but it'd be more compelling if a win was shown on a real
> benchmark. Under normal workloads there is actually little lock contention
> in the Linux kernel, and hence I think scope for wins are limited.
>
> Also, pv_ops Linux already has some extra smartness in its spinlock
> implementation. A spinner will sleep after some time, making it more likely
> that the lock holder will run (who then wakes the sleeper when the lock is
> released). You'd need to compare with that approach (which required no extra
> hypervisor interfaces).
Sure, my benchmark is a very special case :-)
The advantage of my solution is a general mechanism to avoid preemption of
a vcpu in critical sections instead of dealing with it after it has occured.
Is the pv_ops Linux capable to deal with held locks in interrupt handling?
What about other code paths which should be completed in short time?
About real world applications:
Again 4 vcpus pinned to one physical cpu, 3 files copied via scp to the test
machine at the same time, each file about 50 MB.
Linux-xen from xensource: about 1:50 elapsed time for each job
My modified Linux: about 0:50 elapsed time
Juergen
--
Juergen Gross Principal Developer
IP SW OS6 Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
Otto-Hahn-Ring 6 Internet: www.fujitsu-siemens.com
D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|