On Sun, 6 May 2001, Chris Wedgwood wrote:
> On Sat, May 05, 2001 at 11:34:16AM -0500, Mitch Adair wrote:
>
> Wouldn't that be lot of the same issues as a "swapoff" with some
> portion of that in use? (except for the kernel data case of
> course...)
>
> No. Swapoff makes pages allocated to userland applications in swap
> move back into main memory -- this is much easier because:
>
> - the pages are on disk, we _know_ the aren't locked my mlock or
> pinned for IO (kiobufs, whatever)
>
> - there are no kernel pages/buffers in this area, even harder than
> the above to deal with
Details, details ... ;)
For the "pinned for IO" case, we can simply wait until they're
unpinned, this shouldn't take too long. Mlock isn't an issue
either, just remove the page from the page tables, relocate the
page and put it back. This may in theory violate some mlock
behaviour, but in practice it'll be no worse than normal
scheduling latency.
Kernel pages/buffers are no big deal since they're accessed
through the kernel's page tables (for which the same rule
applies as what we do with the mlock()ed pages).
regards,
Rik
-- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:22 EST