summaryrefslogtreecommitdiff
path: root/hurd/running/qemu/discussion.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2011-06-15 22:54:09 +0200
committerThomas Schwinge <thomas@schwinge.name>2011-06-15 22:54:09 +0200
commita5b95baab6b4512ceaef8749a29ed7b3685b4125 (patch)
tree88c0ff2e405ad487a6923da915700179eba35746 /hurd/running/qemu/discussion.mdwn
parenta54427376610d8c5f386c27ac7634bfb127b853c (diff)
Some more bits from IRC and elsewhere.
Diffstat (limited to 'hurd/running/qemu/discussion.mdwn')
-rw-r--r--hurd/running/qemu/discussion.mdwn92
1 files changed, 92 insertions, 0 deletions
diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn
index fd0df4c5..1ce14b01 100644
--- a/hurd/running/qemu/discussion.mdwn
+++ b/hurd/running/qemu/discussion.mdwn
@@ -50,3 +50,95 @@ The problem is actually that the linux block cache doesn't make any consistency
between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings
won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6
directly to qemu and it will be fine.
+
+
+# Host-side Writeback Caching
+
+IRC, freenode, #hurd, 2011-06-07
+
+ <braunr> hm, i guess i should have used cache=writeback with kvm before
+ starting the debian installer :/
+ <braunr> ah yes, much better
+ <braunr> this shows how poor the state of our I/O drivers and subsystem is
+ :/
+ <antrik> indeed... still no clustered pageout :-(
+ <braunr> and no I/O scheduler either
+ <braunr> although an I/O scheduler has limited value without clustered
+ pageouts
+ <braunr> since one of its goals is to pack related I/O requests together eh
+ <braunr> i wonder if the wiki mentions using cache=writeback to speed up
+ qemu performances
+ <braunr> it would help those unable to use kvm a lot
+ <braunr> and even those running kvm too
+ <braunr> kvm -m $RAM \ -monitor stdio \ -drive
+ cache=writeback,index=0,media=disk,file=hd0.img \
+ <braunr> etc..
+ <braunr> the idea is that qemu doesn't open its disk file synchronously
+ <braunr> changes are queued in the host page cache before being flushed to
+ the disk image
+ <braunr> but if you brutally close your qemu instance, you're likely to
+ loose file system consistency
+ <braunr> ext2fs will think it has committed its metadata to the disk, but
+ the disk image won't be updated synchronously
+ <braunr> on my machine (which is quite fast), my kvm has installed debian
+ like 10 times faster than without the option
+ <antrik> braunr: I don't think killing qemu should hurt in this
+ case... probably only matters when the host machine dies
+ <braunr> antrik: ah yes, right
+ <braunr> it really makes everything faster, even downloading, since I/O
+ requests aren't interleaved between networking RPCs
+ <antrik> regarding I/O sheduler... this discussion came up before, but I
+ don't remember the outcome -- doesn't the glued Linux driver actually
+ come with one?
+ <braunr> i don't remember either
+ <antrik> braunr: err... I don't think interleaving has anything to do with
+ it... I guess it's simply the fact that downloading writes the result to
+ disk, which suffers from lacking clustered pageout like everything else
+ <antrik> (my internet connection is too slow though to notice :-) )
+ <braunr> well, if there is no I/O during downloading, downloading is faster
+ :)
+
+IRC, freenode, #hurd, 2011-06-08
+
+ <braunr> youpi: does xen provide disk caching options ?
+ <youpi> through a blktap, probably
+ <braunr> ok
+
+([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.)
+
+ <braunr> we should find the pages mentioning qemu on the wiki and add the
+ options to enable disk image caching
+ <braunr> it really makes the hurd run a lot faster
+ <braunr> as a workaround for emulators until I/O is reworked, ofc
+
+IRC, freenode, #hurd, 2011-06-09
+
+ <gnu_srs> braunr recommends to use writeback caching with kvm. Is this
+ really recommended with the frequent crashes I experience?
+ <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not
+ killing it), there should be no difference
+ <jkoenig> I think the host's stability is what matters
+ <jkoenig> the data presumably sits in linux's cache even if qemu dies
+ violently
+ <gnu_srs> But the freezes I see force me to kill kvm :-(
+ <youpi> maybe kvm doesn't even do caching indeed, I don't know
+ <youpi> gnu_srs: you can quit even when frozen
+ <youpi> use the console
+ <youpi> (the kvm console)
+ <jkoenig> gnu_srs, "Writeback caching will report data writes as completed
+ as soon as the data is present in the host page cache. This is safe as
+ long as you trust your host. If your host crashes or loses power, then
+ the guest may experience data corruption." (from the qemu manpage)
+
+IRC, freenode, #hurd, 2011-06-11
+
+ <gnu_srs> braunr: If you are online. For me setting the parameters -drive
+ cache=writeback,index=0,media=disk,file=hd0.img does not show any speed
+ improvement at all compared to the default.
+ <braunr> gnu_srs: what's your complete qemu command line ?
+ <gnu_srs> kvm -m 1024 -net nic,model=rtl8139 -net
+ user,hostfwd=tcp::5556-:22 -drive
+ cache=writeback,index=0,media=disk,file=hd0.img -cdrom netinst.iso
+ <braunr> what qemu version ?
+ <gnu_srs> qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until
+ tomorrow again.