[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: Fwd: Faster resuming of suspend technology.
Hi. On Tuesday 28 March 2006 09:57, Jun OKAJIMA wrote: > >I wasn't thinking suspend2 was the topic, but I'll freely admit my bias > > and say I think it's the best tool for the job, for a number of reasons: > > > >First, speed is not the only criteria that should be considered. There's > > also memory overhead, the difference in speed post-resume, reliability, > > flexibility and the list goes on. > > > >Second, Xen would not be the most practical candidate now. It would be > > slower than suspend2 because suspend2 is reading the image as fast as the > > hardware will allow it (Ok. Perhaps algorithm changes could make small > > improvements here and there). In contrast, what is Xen doing? I'm not > > claiming knowledge of its internals, but I'm sure it will have at least > > some emphasis on keeping other vms (or whatever it calls them) running > > and interactive while the resume is occuring. It will therefore surely be > > resuming at something less than the fastest possible rate. > > > >Additionally, Xen cannot solve the problems raised by the kernel lacking > >complete hotplug support. Only further development in the kernel itself > > can address those issues. > > I made very easy testing. > > H/W > CPU:Sempron64 2600+ > MEM:1G for Xen3.0 (I put 768MB for dom0, and 256MB for domU) > 256MB for swsusp2 > WAN:100Mbps FTTH ( up to about 8MBytes/sec , from ISP's web server). > HDD:250G 7200rpm ATA > DVD:x16 DVD-R ATA > S/W > SuSE10 with Xen3.0 > Using KDE3 desktop, with Firefox and OOo 2.0 Writer launched. > > Performance: > swsusp2 -> about 10sec after "uncompressing Linux kernel". > (from HDD, of course.) How was suspend2 configured? On a 7200rpm ATA drive, I'd expect 36MB/s throughput. That alone would give you your 10s. But if you add LZF compression to the mix, you should be able to resume in half the time (literally - LZF usually acheived ~50% compression on an image). > Xen resume -> almost same! But needs to boot dom0 first. Impressive. I was afraid it might take much longer. Is that getting all the image in, or is more of an image pulled in as necessary? > On Xen experiment, I booted dom0 from HDD, but loaded the suspend image > from x16 DVD-R. And, it resumed about in 10sec including decompressing > time of suspend image. This means, Xen can resume almost same speed > as swsusp2 from DVD-R, with H/W abstraction which current swsusp2 lacks. > (Note: I did vnc reconnection workaround manually, so the time is just > an estimation.) > And, for example, if you boot dom0 up within 10 sec, ( and this > is quite possible, check my site http://www.machboot.com/), you can get > KDE3+FF1.5+OOo2 workinig within 20sec measured from ISOLINUX loaded, > with x16 DVD-R. Yes, DVD is not slow any more!. > > And, I also tried to do Xen resume from Internet. > What I did was very easy. Just did like this. > (Sorry, no gpg yet.) > # wget $URL -o - | gzip -d > /tmp/$TMP.chk && xm restore /tmp/$TMP.chk > > The result is, I succeeded to "boot" (actually resume) KDE3+FF1.5+OOo2 > in about 15 sec from Internet!. I believe this is the fastest record of > Internet booting ever. Impressive! > What I want to say is, using Xen suspend is one way to "boot" your desktop > faster, especially if you use big apps and big window manager. > > Note: This experiment is very easy one, and no guarantee of correctness or > reproducitivity. Must have many mistakes and misunderstanding and > misconception, so on. I am afraid that even me could not reproduce it. > So, dont accept this figure on faith, but treat as just one suggestion. > But, I believe my suggestion must be meaningful one. > Dont you want to boot your desktop within 20 sec from x48 CD-R? > I suggest that this is not just a dream, but maybe feasible. For live cds, it might be attractive, but for your average hdd based installation, I wouldn't think that using the cd would be that interesting. Nevertheless, yes - booting more quickly from whatever media is desirable. > >> I admit that Jim Crilly's concern is right, but with using Xen suspend, > >> it can be solved very easily. What you do is just like this: > >> [Xen DOM0]# wget (pretend url removed so LKML servers don't think this is spam) > >> gpg --verify debian.image > >> [Xen DOM0]# xen --resume debian.image > > > >Given this example, I guess you're talking about Xen (or vmware for that > >matter) providing an abstraction of the hardware that's really available. > >Doesn't this still have the problems I mentioned above, namely that your > > Xen image can't possibly have support for any possible hardware the user > > might have, allowing that hardware to be used with full functionality and > > full speed. Surely such any such solution must be viewed as second best, > > at best? > > I have not checked this feature yet. > I only have one Xen installed PC and to make matters worse, > the condition of the PC is very unstable, so it is a bit tough > to check this by myself. > > Do somebody know about this? > I mean, Xen really does not have an abstraction layer of the H/W? Yeah, I guess it would too. Sorry for my wonky thinking there. > I think it must have and you can use the same suspend image on all Xen PCs. Yeah. Regards, Nigel
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
Lists.xenproject.org is hosted with RackSpace, monitoring our