From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
kvm list <kvm@vger.kernel.org>,
dipankar@in.ibm.com, Alexander Graf <agraf@suse.de>,
qemu-devel Developers <qemu-devel@nongnu.org>,
Chris Wright <chrisw@sous-sol.org>,
bharata@linux.vnet.ibm.com, Vaidyanathan S <svaidy@in.ibm.com>
Subject: Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
Date: Thu, 22 Dec 2011 20:04:02 +0100 [thread overview]
Message-ID: <1324580642.24803.33.camel@twins> (raw)
In-Reply-To: <20111222110108.GA7893@amt.cnet>
On Thu, 2011-12-22 at 09:01 -0200, Marcelo Tosatti wrote:
>
> > No virt is crap, it needs to die, its horrid, and any solution aimed
> > squarely at virt only is shit and not worth considering, that simple.
>
> Removing this phrase from context (feel free to object on that basis
> to the following inquiry), what are your concerns with virtualization
> itself? Is it the fact that having an unknownable operating system under
> your feet uncomfortable only, or is there something else? Because virt
> is green, it saves silicon.
No, you're going the wrong way around that argument. Resource control
would save the planet in that case. That's an entirely separate concept
from virtualization. Look how much cgroup crap you still need on top of
the whole virt thing.
Virt deals with running legacy OSs, mostly because you're in a bind and
for a host of reasons can't get this super critical application you
really must have running on your new and improved platform.
So you emulate hardware to run the old os, to run the old app or
somesuch nonsense.
Virt really is mostly a technical solution to a mostly non-technical
problem.
There's of course the debug angle, but I've never really found it
reliable enough to use in that capacity, give me real hardware with a
serial port any day of the week.
Also, it just really offends me, we work really hard to make stuff go as
fast as possible and then you stick a gigantic emulation layer in
between and complain that shit is slow again. Don't do that!!
next prev parent reply other threads:[~2011-12-22 19:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-29 18:45 [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding Bharata B Rao
2011-10-29 19:57 ` Alexander Graf
2011-10-30 9:32 ` Vaidyanathan Srinivasan
2011-11-08 17:33 ` Chris Wright
2011-11-21 15:18 ` Bharata B Rao
2011-11-21 15:25 ` Peter Zijlstra
2011-11-21 16:00 ` Bharata B Rao
2011-11-21 17:03 ` Peter Zijlstra
2011-11-21 22:50 ` Chris Wright
2011-11-22 1:57 ` Anthony Liguori
2011-11-22 1:51 ` Anthony Liguori
2011-11-23 15:03 ` Andrea Arcangeli
2011-11-23 18:34 ` Alexander Graf
2011-11-23 20:19 ` Andrea Arcangeli
2011-11-30 16:22 ` Dipankar Sarma
2011-11-30 16:25 ` Peter Zijlstra
2011-11-30 16:33 ` Chris Wright
2011-11-30 17:41 ` Andrea Arcangeli
2011-12-01 17:25 ` Dipankar Sarma
2011-12-01 17:36 ` Andrea Arcangeli
2011-12-01 17:49 ` Dipankar Sarma
2011-12-01 17:40 ` Peter Zijlstra
2011-12-22 11:01 ` Marcelo Tosatti
2011-12-22 17:13 ` Anthony Liguori
2011-12-22 17:55 ` Marcelo Tosatti
2011-12-22 19:04 ` Peter Zijlstra [this message]
2011-12-22 11:24 ` Marcelo Tosatti
2011-11-21 18:03 ` Avi Kivity
2011-11-21 19:31 ` Peter Zijlstra
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=1324580642.24803.33.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=aarcange@redhat.com \
--cc=agraf@suse.de \
--cc=bharata@linux.vnet.ibm.com \
--cc=chrisw@sous-sol.org \
--cc=dipankar@in.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=svaidy@in.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).