Re: Faster resuming of suspend technology.

[Nigel Cunningham <ncunningham@cyclades.com>]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

Hi.

On Saturday 11 March 2006 22:17, Jun OKAJIMA wrote:
> >My version doesn't have this problem by default, because it saves a full
> > image of memory unless the user explicitly sets a (soft) upper limit on
> > the image size. The image is stored as contiguously as available storage
> > allows, so rereading it quickly isn't so much of an issue (and far less
> > of an issue than discarding the memory before suspending and faulting it
> > back in from all over the place afterwards).
>
> 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".

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

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

Regards,

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]