All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: xuehai zhang <hai@cs.uchicago.edu>
Cc: "Petersson, Mats" <mats.petersson@amd.com>,
	Kate Keahey <keahey@mcs.anl.gov>,
	Xen Mailing List <xen-devel@lists.xensource.com>,
	Tim Freeman <tfreeman@mcs.anl.gov>
Subject: Re: open/stat64 syscalls run faster on Xen VM than standard Linux
Date: Mon, 28 Nov 2005 13:37:08 -0600	[thread overview]
Message-ID: <438B5C64.5090505@us.ibm.com> (raw)
In-Reply-To: <438B3B88.8040702@cs.uchicago.edu>

xuehai zhang wrote:

> So, the benchmark experiments I've done so far suggests XenLinux using 
> loopback files as VBD backends shows better performance (faster 
> execution) on part of the system calls like open and stat64, but it 
> shows worse performance (slower execution) on other system calls like 
> write than the standard Linux. Does this mean different applications 
> may have different execution behaviors on VM than on the standard 
> Linux? In other words, some applications run faster on VM and some 
> slower, comparing with the physical machine?

I really want to stress here that your results do not mean system calls 
are faster in Xen (or with a loopback device).  You're seeing the 
effects of caching which are probably sub-optimal for overall performance.

A more meaningful benchmark here is to take a syscall intensive 
workload, and measure the thoroughput.  You'll likely find that the 
syscall performance is actually worse because when you start missing the 
cache you're going to get huge delays in read-ahead.

Be wary of microbenchmarks, they often are way off from real-world 
scenarios.

As for write performance, in general, read and write performance are 
going to be measurably slower in Xen than on bare-metal Linux.  It 
almost has to be by definition.  The hope is that the difference in 
performance will be neglible especially considering the improved 
thoroughput from greater utiliziation of the underlying hardware.

Regards,

Anthony Liguori

  reply	other threads:[~2005-11-28 19:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-28 16:15 open/stat64 syscalls run faster on Xen VM than standard Linux Petersson, Mats
2005-11-28 17:16 ` xuehai zhang
2005-11-28 19:37   ` Anthony Liguori [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-11-29 12:59 Petersson, Mats
2005-11-29 13:48 ` xuehai zhang
2005-11-28 18:17 Petersson, Mats
2005-11-28 14:45 Petersson, Mats
2005-11-28 15:28 ` xuehai zhang
2005-11-28 15:50 ` xuehai zhang
2005-11-28 16:07   ` Stephen C. Tweedie
2005-11-28 16:27     ` xuehai zhang
2005-11-28 17:10       ` Stephen C. Tweedie
2005-11-29  4:50         ` Tim Freeman
2005-11-29 13:27         ` xuehai zhang
2005-11-28 14:36 Petersson, Mats
2005-11-28 14:47 ` xuehai zhang
2005-11-28  8:21 xuehai zhang
2005-11-28 14:38 ` Anthony Liguori
2005-11-28 14:59   ` xuehai zhang
2005-11-29 12:39   ` xuehai zhang
2005-11-29 12:58     ` xuehai zhang

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=438B5C64.5090505@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=hai@cs.uchicago.edu \
    --cc=keahey@mcs.anl.gov \
    --cc=mats.petersson@amd.com \
    --cc=tfreeman@mcs.anl.gov \
    --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.