Fwd: Faster resuming of suspend technology.

[Jun OKAJIMA]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/