Re: Faster resuming of suspend technology.

[Nigel Cunningham <ncunningham@cyclades.com>]

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

Hi.

On Saturday 11 March 2006 03:04, Jun OKAJIMA wrote:
> As you might know, one of the key technology of fast booting is suspending.
> actually, using suspending does fast booting. And very good point is
> not only can do booting desktop and daemons, but apps at once.
> but one big fault --- it is slow for a while after booted because of HDD
> thrashing. (I mention a term suspend as generic one, not refering only to
> Nigel Cunningham's one)
>
> One of the solution of thrashing issue is like this.
> 1. log disk access pattern after booted.
> 2. analyze the log and find common disk access pattern.
> 2. re-order a suspend image using the pattern.
> 3. read-aheading the image after booted.
>
> so far is okay. this is common technique to reduce disk seek.
>
> The problem of above way is,  "Is there common access pattern?".
> I guess there would be.
> The reason is that even what user does is always different, but what pages
> it needs has common pattern. For example, pages which contain glibc or gtk
> libs are always used. So, reading ahead these pages is meaningful, I
> suppose.
>
> What you think? Your opinion is very welcome.
>
>
>                  --- Okajima, Jun. Tokyo, Japan.
>                      http://www.machboot.com

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

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.

Hope that helps.

Nigel

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