From: Juergen Gross <juergen.gross@fujitsu-siemens.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [Patch 2 of 2]: PV-domain SMP performance Linux-part
Date: Tue, 20 Jan 2009 08:56:11 +0100 [thread overview]
Message-ID: <4975839B.8050305@fujitsu-siemens.com> (raw)
In-Reply-To: <de76405a0901190932r21fc323et96e7516649e1dc55@mail.gmail.com>
George Dunlap wrote:
> On Mon, Jan 12, 2009 at 12:55 PM, Juergen Gross
> <juergen.gross@fujitsu-siemens.com> wrote:
>> Conclusion:
>> -----------
>> Differences not really big, but my "no deschedule" patch had least elapsed
>> time for build-jobs, while scp was able to transfer same amount of data as
>> in slower original system.
>> The "Yield in spinlock" patch had slightly better dbench performance, but
>> interactive shell commands were a pain sometimes! I suspect some problem in
>> George's patches during low system load to be the main reason for this
>> behaviour. Without George's patches the "Yield in spinlock" was very similar
>> to the original system.
>
> Hmm, the shell performance is a little worrying. There may be
> something strange going on...
>
> Without my patches (at least, without the "yield reduces priority"
> patch), "yield" is basically a no-op, so "yield in spinlock" is
> functionally equivalent to the original system.
>
> According to your numbers, the "user time" and "system time" were
> exactly the same (only 0.6 seconds longer on system time), even though
> the overall build took 52 seconds longer. Is it possible that the
> "yield" patches actually made it run less often?
I assume this could be possible. Do you think the following is reasonable?
If a vcpu is waiting for a lock it will yield, which will reduce it's
priority. This will increase the latency, if other vcpus are ready to run.
Normally the vcpu waiting for a lock is in some kind of critical path which
might be delayed significantly by the yield.
In sum the complete machine isn't burning cycles spinning, but the code
paths with lock conflicts are the loosers...
>
> scp works over tcp, which is often sensitive to latency; so it's
> possible that the lowered priority on yield caused "hiccoughs", both
> in the scp connections, and the interactive shell performance.
This sounds reasonable to me.
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
next prev parent reply other threads:[~2009-01-20 7:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 12:22 [Patch 2 of 2]: PV-domain SMP performance Linux-part Juergen Gross
2008-12-17 15:06 ` Jan Beulich
2008-12-18 7:18 ` Juergen Gross
2008-12-18 7:41 ` Jan Beulich
2008-12-19 8:12 ` Juergen Gross
2008-12-19 9:10 ` Keir Fraser
2008-12-19 9:25 ` Juergen Gross
2008-12-19 9:56 ` Keir Fraser
2009-01-16 7:16 ` Juergen Gross
2009-01-16 7:38 ` Venefax
2009-01-16 7:48 ` Juergen Gross
2009-01-16 7:57 ` Venefax
2009-01-16 8:19 ` Juergen Gross
2009-01-16 10:16 ` James Harper
2009-01-16 10:31 ` Juergen Gross
2009-01-16 10:41 ` Keir Fraser
2009-01-16 11:01 ` James Harper
2009-01-16 11:14 ` Keir Fraser
2009-01-16 11:18 ` Jan Beulich
2009-01-16 14:40 ` Steve Prochniak
2009-01-16 17:43 ` Jeremy Fitzhardinge
2009-01-16 8:17 ` Keir Fraser
2009-01-16 9:36 ` Juergen Gross
2009-01-16 9:53 ` Keir Fraser
2009-01-16 17:41 ` Jeremy Fitzhardinge
2009-01-19 17:15 ` George Dunlap
2009-01-20 20:12 ` Jeremy Fitzhardinge
2008-12-19 9:33 ` Jan Beulich
2008-12-19 9:56 ` Keir Fraser
2008-12-19 15:15 ` George Dunlap
2009-01-12 12:55 ` Juergen Gross
2009-01-19 17:32 ` George Dunlap
2009-01-20 7:56 ` Juergen Gross [this message]
2008-12-19 10:06 ` Juergen Gross
2008-12-19 10:36 ` Jan Beulich
2008-12-19 10:42 ` Juergen Gross
2008-12-19 10:48 ` 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=4975839B.8050305@fujitsu-siemens.com \
--to=juergen.gross@fujitsu-siemens.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=keir.fraser@eu.citrix.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.