On Wed, 4 Apr 2007, Andrew Morton wrote: > > The treatment is identical to clean swapcache pages, with the sole > exception that they don't actually consume any swap space - hence the fake > swapcache entry thing.
I see, sneaking through try_to_unmap's anon PageSwapCache assumptions as simply as possible - thanks. (Coincidentally, Andrea pointed to precisely the same issue in the no PAGE_ZERO thread, when we were toying with writable but clean.) > One thing which we haven't sorted out with all this stuff: once the > application has marked an address range (and some pages) as > whatever-were-going-call-this-feature, how does the application undo > that change? By re-referencing the pages. (Hmm, so an incorrect app which accesses "free"d areas, will undo it: well, okay, nothing terrible about that.) > What effect will things like mremap, madvise and mlock have upon > these pages? mlock will undo the state in its make_pages_present: I guess that should happen in or near follow_page's mark_page_accessed. mremap? Other madvises? Nothing much at all: mremap can move them around, and the madvises do whatever they do - I don't notice any problem in that direction, but it'll be easier when we have an implementation to poke at. Hugh - 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/
