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

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


  • To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 20 Jan 2009 08:56:11 +0100
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 19 Jan 2009 23:56:51 -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=vtStaSmZ0JwgGrxUZnXNaossvc6kMGYDmOUsVodJF5AFq83XmhOf9KxD jUizqH5C5vpbJ96PDjfiInb7GgzPsAoYIdA5/7KU86Mpj813MNCjo0MF9 5wQWaTQyuFI0vxq;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

George Dunlap wrote:
> On Mon, Jan 12, 2009 at 12:55 PM, Juergen Gross
> <juergen.gross@xxxxxxxxxxxxxxxxxxx> 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@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


 


Rackspace

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