Re: Faster resuming of suspend technology.

[Jun OKAJIMA]

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



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

                  --- Okajima, Jun. Tokyo, Japan.


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