From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Juergen Gross <juergen.gross@fujitsu-siemens.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Patch 0 of 2]: PV-domain SMP performance
Date: Wed, 17 Dec 2008 15:05:09 +0000 [thread overview]
Message-ID: <C56EC5A5.20543%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <49490AA0.3080703@fujitsu-siemens.com>
On 17/12/2008 14:20, "Juergen Gross" <juergen.gross@fujitsu-siemens.com>
wrote:
> 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?
Yes the approach is the other way round to yours. It handles irq-safe locks
just fine; no reason for it not to.
> 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
So this provides great wins for those who run multi-vcpu VMs on a single
physical CPU? ;-) Actually getting a speedup on this benchmark even in that
configuration is a surprise I will admit -- I'd expect most time to be spent
in sshd in user space. By 0:50 for each job you mean 0:50 for 50MB? That's
10Mbps and I wouldn't even expect a single CPU working alone to be breaking
a sweat. Weird...
-- Keir
next prev parent reply other threads:[~2008-12-17 15:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 12:21 [Patch 0 of 2]: PV-domain SMP performance Juergen Gross
2008-12-17 12:38 ` Keir Fraser
2008-12-17 14:20 ` Juergen Gross
2008-12-17 15:05 ` Keir Fraser [this message]
2008-12-18 12:06 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C56EC5A5.20543%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=juergen.gross@fujitsu-siemens.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.