Re: Faster resuming of suspend technology.

[Nigel Cunningham <ncunningham@cyclades.com>]

Hi.

On Monday 13 March 2006 03:54, Jim Crilly wrote:
> On 03/12/06 06:26:17PM +0900, Jun OKAJIMA wrote:
> > >> Yes, right. In your way, there is no thrashing. but it slows booting.
> > >> I mean, there is a trade-off between booting and after booted.
> > >> But, what people would want is always both, not either.
> > >
> > >I don't understand what you're saying. In particular, I'm not sure
> > > why/how you think suspend functionality slows booting or what the
> > > tradeoff is "between booting and after booted".
> >
> > Sorry, I used words in not usual way.
> > I refer "booting" as just resuming. And "after booted" means "after
> > resumed". In other words, I treat swsusp2 as not note PC's hibernation
> > equivalent, but just for faster booting technology.
> > So, What I wanted to say was,
> >
> >   --- Reading all image in advance ( your way) slows resuming itself.
> >   --- Reading pages on demand ( e.g. VMware) slows apps after resumed.
> >
> > Hope my English is understandable one...
>
> But you have to read all of the pages at some point so the hard disk is
> going to be the bottleneck no matter what you do. And since Suspend2
> currently saves the cache as a contiguous stream, possibly compressed, it
> should be a good bit faster than seeking around the disk loading the files
> from the filesystem.

Agreed.

> > >> 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.

> > >> >That said, work has already been done along the lines that you're
> > >> > describing. You might, for example, look at the OLS papers from last
> > >> > year. There was a paper there describing work on almost exactly what
> > >> > you're describing.
> > >>
> > >> Could I have URL or title of the paper?
> > >
> > >http://www.linuxsymposium.org/2005/. I don't recall the title now,
> > > sorry, and can't tell you whether it's in volume 1 or 2 of the
> > > proceedings, but I'm sure it will stick out like a sore thumb.
> >
> > I checked the URL but could not find the paper,
> > with keywords of "Cunningham" or "swsusp" or "suspend".
> > Could you tell me any keyword to find it?
>
> I took a quick look at the PDFs and I believe the section Nigel is talking
> about is called "On faster application startup times: Cache stuffing, seek
> profiling, adaptive preloading" in volume 1.

Yes, that's the one. Sorry - I didn't mean to give the impression that I wrote 
it. I know about it because I attended the talk.

Regards,

Nigel

Attachment: pgp7nZ2KTlCpp.pgp
Description: PGP signature