WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Fwd: Faster resuming of suspend technology.

>
>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.)
Xen resume -> almost same! But needs to boot dom0 first.

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.

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.

>> 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
>> http://www.geocity.com/1235089/suspend_image/debian.image [Xen DOM0]# 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?
I think it must have and you can use the same suspend image on all Xen PCs.

              --- Okajima, Jun. Tokyo, Japan.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>