>
>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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
