From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
Date: Fri, 14 Sep 2012 12:32:17 +0200 [thread overview]
Message-ID: <505307B1.10408@siemens.com> (raw)
In-Reply-To: <20120914102044.GL6819@redhat.com>
On 2012-09-14 12:20, Daniel P. Berrange wrote:
> On Fri, Sep 14, 2012 at 12:12:43PM +0200, Jan Kiszka wrote:
>> On 2012-09-14 12:03, Michael Tokarev wrote:
>>> On 14.09.2012 14:00, Jan Kiszka wrote:
>>> []
>>>> The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on
>>>> the TCG side: We measured noticeable performance benefits when running
>>>> 32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I
>>>> don't have numbers at hand, but colleagues decided to use the 32-bit
>>>> version for that reason (when no KVM is available).
>>>
>>> Interesting. Maybe someone should look at the difference on TCG side
>>> and merge interesting bits from i386 to x86_64... :)
>>
>> I suppose the difference - for our use cases at least - lies in the
>> different register and address sizes. Maybe there is room for more
>> runtime optimizations, we never looked in that details as -i386 still
>> works fine. And, if you are on 32-bit host (see below) - but we aren't,
>> qemu-system-x86_64 hurts even more.
>>
>>>
>>> The thing is: x86_64 becomes the only x86 platform these days, or at
>>> least the MAIN platform.
>>
>> I know, and I'm telling everyone. Still, too many crazy people keep on
>> installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will
>> improve this.
>
> It is quite depressing that 32-bit still accounts for 55% of deployed
> Fedora installs:
>
> http://smolt.fedoraproject.org/static/stats/stats.html
>
> That said, a year ago it was even worse with 32-bit up in 70% region
There is a nice comment by Steven that I pinned on my wall, the last
paragraph text-marked:
http://lkml.indiana.edu/hypermail/linux/kernel/1206.1/00445.html. These
days, I prefer to just point people to that printout instead of arguing.
Didn't help yet, unfortunately, to convince our corporate VPN vendor to
finally support 64-bit with his proprietary clients. Maybe because they
didn't visit my office yet.
The problem is also that some distros default the download to 32-bit
when asking for a desktop, e.g. Ubuntu or OpenSUSE. Kudos to Fedora for
not doing this.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-09-14 10:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 7:39 [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ? Michael Tokarev
2012-09-14 9:33 ` Daniel P. Berrange
2012-09-14 9:39 ` Michael Tokarev
2012-09-14 10:00 ` Jan Kiszka
2012-09-14 10:03 ` Michael Tokarev
2012-09-14 10:12 ` Jan Kiszka
2012-09-14 10:20 ` Daniel P. Berrange
2012-09-14 10:32 ` Jan Kiszka [this message]
2012-09-14 10:39 ` Peter Maydell
2012-09-14 12:24 ` Aurelien Jarno
2012-09-14 19:29 ` Blue Swirl
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=505307B1.10408@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=berrange@redhat.com \
--cc=mjt@tls.msk.ru \
--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.