On 08/04/2010 08:27 PM, Alexander Graf wrote:
Well, it isn't. Two external projects already use it. You can't change it due to the needs to live migrate from older versions.
You can always extend it. You can even break it with a new -M.
Yes. But it's a pain to make sure it all works out. We're already
suffering from this where we have no choice, why do it where we have a
choice?
It's not wrong in itself, but using it with supersized initrds is wrong. The data is stored in qemu, host pagecache, and the guest, so three copies, it's limited by guest RAM, has to be live migrated. Sure we could optimize it, but it's better to spend our efforts on more mainstream users.
It's only stored twice. The host pagecache copy is gone during the lifetime of the VM.
It has still evicted some other pagecache. Footprint is footprint.
300MB to cat some file in a guest.
Migration also doesn't make sense for most -kernel/-initrd use cases.
You're just inviting a bug report here. If we add a feature, let's make
it work.
And it's awesome for fast prototyping. Of course, once that fast becomes dog slow, it's not useful anymore.
For the Nth time, it's only slow with 100MB initrds.
I bet within the time everybody spent on this thread we would have a working and stable DMA fw_cfg interface plus extra spare time for supporting breakage already.
The time would have been better spent improving kvm's pio or porting
libguestfs to use a cdrom. I'm also hoping to get the point across that
adding pv interfaces like crazy is not sustainable.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
