From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 12 Jun 2008 22:38:35 -0500 From: "Lorenzo Fernando Bivens de la Fuente" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080613015449.GA12686@companion-cube> Subject: Re: [9fans] I/O load crashes Qemu Topicbox-Message-UUID: be260da0-ead3-11e9-9d60-3106f5b1d025 Thoughts: + Running Plan 9 on qemu is slow (when doing disk access) (the ethernal DMA wiwi bla bla bla) + qcow2 is quality challenged, but I think that the standard plan9.img ain't qcow2 +kqemu has worked for me very well... but I have not benchmarked it. + Unpacking 100 MiB sounds like a lot of I/O... Ergo a lot of "disk" ergo a lot of no-dma bottleneck Good luck On 6/12/08, Pietro Gagliardi wrote: > On Jun 12, 2008, at 9:54 PM, Venkatesh Srinivas wrote: > > > > Hi, > > > > I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O > > demanding such as unpacking a ~100MB tarball, qemu locks up and refuses > > further connections (via vnc, or gdb for example). I am using fossil > > alone. This behavior occurs whether kqemu is enabled or not, though it > > happens a lot faster w/o kqemu. > > > > Has anyone else noticed anything like this? Any thoughts about running > > Plan 9 in qemu? > > > > Thanks, > > --vs > > > > > > Compressed disc image (qcow2)? That's what screwed up my fossil+venti. > > >