Re: [Patch 0 of 2]: PV-domain SMP performance

[Juergen Gross <juergen.gross@fujitsu-siemens.com>]

Keir Fraser wrote:
> On 17/12/2008 12:21, "Juergen Gross" <juergen.gross@fujitsu-siemens.com>
> 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@fujitsu-siemens.com
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html