This is forwarded from Cunningham''s mail which we failed to post LKML
because of false positive of LKML''s spam filter.
I also post this to Xen-devel, swsusp2-devel.
For the purpose of faster booting(=resuming, in this case),
You think what suspend technology is good in what aspect?
--- Okajima.
-----------
Hi.
On Saturday 18 March 2006 03:46, Jun OKAJIMA wrote:> >> > >> Especially, your way has problem if you boot( resume
) not from HDD
> >> > >> but for example, from NFS server or CD-R or even
from Internet.
> >> > >
> >> > >Resuming from the internet? Scary. Anyway, I hope
I''ll understand
> >> > > better what you''re getting at after your next
reply.
> >> >
> >> > In Japan, it is not so scary.
> >> > We have 100Mbps symmetric FTTH ( optical Fiber To The Home),
and
> >> > more than 1M homes have it, and price is about 30USD/month.
> >> > With this, theoretically you can download 600MB ISO image in
one min,
> >> > and actually you can download 100MBytes suspend image within
30sec.
> >> > So, not click to run (e.g. Java applet) but "click to
resume" is not
> >> > dreaming but rather feasible. You still think it is scary on
this
> >> > situation?
> >>
> >> I don''t think the scary part is speed, but security. I
for one wouldn''t
> >> want to resume from an image hosted on a remote machine unless I
had
> >> some way to be sure it wasn''t tampered with, like gpg
signing or
> >> something.
> >
> >Another issues is that at the moment, hotplugging is work in progress.
In
> >order to resume, you currently need the same kernel build
you''re booting
> >with, and the same hardware configuration in the resumed system. As
> > hotplug matures, this restriction might relax, and we could probably
come
> > up with a way around the former restriction, but at the moment, it
really
> > only makes sense to try to resume an image you created using the same
> > machine.
>
> Wait, wait. Let make it clear that what we are discussing.
>
> For me, the theme is "faster resuming with suspend technology",
not
> swsusp2. I mean, in this point of view, the most practical candidate for
> now would be Xen suspend, not swsusp2. Of course, hotplugging once comes,
> swsusp2 will be a good candidate also, and hopefully what I call
"generic
> suspend image" would be possible.
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 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?
Regards,
Nigel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jun OKAJIMA
2006-Mar-27 23:57 UTC
[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@lists.xensource.com http://lists.xensource.com/xen-devel
Nigel Cunningham
2006-Mar-28 00:28 UTC
[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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Mar-28 12:48 UTC
Re: [Xen-devel] Re: Fwd: Faster resuming of suspend technology.
On 28 Mar 2006, at 01:28, Nigel Cunningham wrote:>> I think it must have and you can use the same suspend image on all >> Xen PCs. > > Yeah.Certain CPU features can screw things up. So moving from a CPU that supports SSE2 to one that doesn''t is unlikely to work well, for example. But as long as CPU capabilities are a reasonably close match then yes, you should be able to use a suspend image anywhere. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel