All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aurelien Jarno <aurelien@aurel32.net>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] hw/vexpress: set default block type to SD
Date: Sun, 17 Mar 2013 01:04:37 +0100	[thread overview]
Message-ID: <20130317000437.GA4241@ohm.aurel32.net> (raw)
In-Reply-To: <CAFEAcA9dAecJi0UmHo_0a5qG=hrHWct9ycd+M_645wEtSV+8tw@mail.gmail.com>

On Fri, Mar 15, 2013 at 03:45:11PM +0000, Peter Maydell wrote:
> On 15 March 2013 15:42, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Fri, Mar 15, 2013 at 03:35:48PM +0000, Peter Maydell wrote:
> >> I'm not convinced this is a good thing -- I think you should have
> >> to know that you're attaching an SD card and not a hard disk,
> >> because the performance is much worse. In particular if you
> >> don't specify 'cache=writeback' your performance will be
> >> dreadful, so you need to do something different from hard
> >> disks anyhow.
> 
> > Being a good thing or not, the current code is wrong: the default
> > interface type is set to SCSI (I guess it has been copied from
> > versatilepb.c), while the vexpress machine has no SCSI
> > interface.
> 
> I agree we shouldn't be claiming to have a scsi interface, yes.
> 

Does it means you are going to accept the patch?

In anycase let me give you some more arguments in favor of it. Even if
you believe that users should always provide a cache= argument, I don't
think it should be done by setting a wrong default interfaces. Users are
likely to simply google for a command line and paste it without
understanding the consequences of cache=writeback. The way to go there
is to make the writeback argument mandatory for some machines if you
really believe it's need by all users.

That said I don't share this opinion. I have made some tests comparing
a versatile and a vexpress machine, running Debian Wheezy, armel for the
first one and armhf for the second one. This has been done on a Core i5
2500 machine with a ST2000DM001 hard drive. Here are the results:

                          | boot | install build-dep | build lm-sensors |
  ------------------------+------+-------------------+------------------+
  versatile               | 1:09 |             2:27  |             4:09 |
  versatile cache=wb      | 1:08 |             2:25  |             3:44 |
  vexpress                | 1:11 |             3:07  |             3:49 |
  vexpress cache=wb       | 1:07 |             3:07  |             3:47 |

  Note: the install build-dep time doesn't include the download time.

So even if the two systems are not directly comparable, it shows that
the SD card emulation is indeed slower than the hard disk one. That said
while cache=writeback makes a difference for the versatile platform, it
doesn't really change anything for the vexpress platform. Therefore
forcing the users to add this option doesn't seems to be a good idea.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

  reply	other threads:[~2013-03-17  0:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05  0:19 [Qemu-devel] [PATCH] hw/vexpress: set default block type to SD Aurelien Jarno
2013-03-05  0:22 ` Peter Maydell
2013-03-05  0:44   ` Aurelien Jarno
2013-03-06  9:25     ` Markus Armbruster
2013-03-15 15:35     ` Peter Maydell
2013-03-15 15:42       ` Aurelien Jarno
2013-03-15 15:45         ` Peter Maydell
2013-03-17  0:04           ` Aurelien Jarno [this message]
2013-03-17  0:23             ` Peter Maydell
2013-03-17 10:17               ` Aurelien Jarno
2013-03-17 10:56                 ` Peter Maydell
2013-03-17 18:51             ` Paolo Bonzini
2013-03-17 18:54               ` Peter Maydell
2013-03-17 19:22                 ` Aurelien Jarno
2013-03-18  8:31                 ` Paolo Bonzini
2013-03-17 19:20               ` Aurelien Jarno
2013-03-17 18:28       ` Paolo Bonzini

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=20130317000437.GA4241@ohm.aurel32.net \
    --to=aurelien@aurel32.net \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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.