From a5b95baab6b4512ceaef8749a29ed7b3685b4125 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 15 Jun 2011 22:54:09 +0200 Subject: Some more bits from IRC and elsewhere. --- hurd/running/qemu/discussion.mdwn | 92 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) (limited to 'hurd/running/qemu') 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 + + hm, i guess i should have used cache=writeback with kvm before + starting the debian installer :/ + ah yes, much better + this shows how poor the state of our I/O drivers and subsystem is + :/ + indeed... still no clustered pageout :-( + and no I/O scheduler either + although an I/O scheduler has limited value without clustered + pageouts + since one of its goals is to pack related I/O requests together eh + i wonder if the wiki mentions using cache=writeback to speed up + qemu performances + it would help those unable to use kvm a lot + and even those running kvm too + kvm -m $RAM \ -monitor stdio \ -drive + cache=writeback,index=0,media=disk,file=hd0.img \ + etc.. + the idea is that qemu doesn't open its disk file synchronously + changes are queued in the host page cache before being flushed to + the disk image + but if you brutally close your qemu instance, you're likely to + loose file system consistency + ext2fs will think it has committed its metadata to the disk, but + the disk image won't be updated synchronously + on my machine (which is quite fast), my kvm has installed debian + like 10 times faster than without the option + braunr: I don't think killing qemu should hurt in this + case... probably only matters when the host machine dies + antrik: ah yes, right + it really makes everything faster, even downloading, since I/O + requests aren't interleaved between networking RPCs + 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? + i don't remember either + 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 + (my internet connection is too slow though to notice :-) ) + well, if there is no I/O during downloading, downloading is faster + :) + +IRC, freenode, #hurd, 2011-06-08 + + youpi: does xen provide disk caching options ? + through a blktap, probably + ok + +([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) + + we should find the pages mentioning qemu on the wiki and add the + options to enable disk image caching + it really makes the hurd run a lot faster + as a workaround for emulators until I/O is reworked, ofc + +IRC, freenode, #hurd, 2011-06-09 + + braunr recommends to use writeback caching with kvm. Is this + really recommended with the frequent crashes I experience? + provided that you terminate your kvm normaly (i.e. quitting it, not + killing it), there should be no difference + I think the host's stability is what matters + the data presumably sits in linux's cache even if qemu dies + violently + But the freezes I see force me to kill kvm :-( + maybe kvm doesn't even do caching indeed, I don't know + gnu_srs: you can quit even when frozen + use the console + (the kvm console) + 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 + + 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. + gnu_srs: what's your complete qemu command line ? + 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 + what qemu version ? + qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until + tomorrow again. -- cgit v1.2.3