qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU with KNOPPIX


From: Kuniyasu Suzaki
Subject: Re: [Qemu-devel] QEMU with KNOPPIX
Date: Thu, 26 Aug 2004 16:57:38 +0900 (JST)

Thank you for your good response.

 >>From: "John R. Hogerhuis" <address@hidden>
 >>Subject: Re: [Qemu-devel] QEMU with KNOPPIX
 >>
 >>On Wed, 2004-08-25 at 22:19, Kuniyasu Suzaki wrote:
 >>
 >>> If you have any suggestions, please post.
 >>
 >>Need to think of some ways to speed it up. It took several minutes to
 >>load.
 >>
 >>Where are the possible optimizations?

One idea is to cancel auto-configuration of KNOPPIX because QEMU has
fixed devices. For example,
   boot: knoppix noscsi nousb nopcmcia lang=us screen=800x600 desktop=wmaker

To use light desktop-manager is another key point, because KDE is heavy.

 >>Could we do a "save state" type operation and jump straight to loaded
 >>Knoppix desktop?

This ides sound nice, because it is resemble to my research topic. :-)
   Network Transferable Computer.
   http://staff.aist.go.jp/k.suzaki/English/NTC/

 >>Seems to be a lot of CDROM activity. That is the nature of Knoppix, and
 >>that definitely slows Knoppix down, but for some reason it sounded
 >>really choppy to me. I'm wondering if there is anything we can do to
 >>speed up cd access. Maybe on a machine with a lot of RAM it could be
 >>read into RAM, or perhaps just copied to hard drive in one step and run
 >>from there. Some or all apps could be decompressed. I think Knoppix has
 >>something like this.

Yes, root File System of KNOPPIX is stored to a compressed loop-back
device. It is called "CLOOP". KNOPPIX has boot option to move CLOOP file
to hard disk or RAM disk. It takes time to boot, but response makes
better.

But I think the option is not valuable on QEMU. It makes slow boot on QEMU.
To make short-cut of boot is most important.

 >>It's a complex set up, but some profiling might be in order... see how
 >>well QEMU translation cache is performing, and see if there is a lot of
 >>time spent in certain types of code that could be sped up in QEMU.
 >>
 >>
 >>I agree with you that Kazu's recent QEMU on Windows was indeed the heavy
 >>lifting, but there's still plenty to do on (Knoppix On (QEMU On
 >>Windows)) to make it really usable. Which I think it can be, and on some
 >>machines maybe it already is...

------
suzaki




reply via email to

[Prev in Thread] Current Thread [Next in Thread]