[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 17 Dec 2008 15:20:16 +0100
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 17 Dec 2008 06:21:04 -0800
  • Domainkey-signature: s=s768; d=fujitsu-siemens.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=GTo0scuWjr1ucKrkauOKTMo58nu8PKbcp03hv4GN1AIURnx9VcaiAYn9 MHgnXTXbtqIM25nu3PzYg2HLWBGFwo3ITswweA1aRJcymYuFow9srMdlI gi4qj00uNekDNqz;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.