Re: Extensions to mincore

["Stephen C. Tweedie" <sct@scot.redhat.com>]

Hi,

On Tue, Mar 21, 2000 at 03:11:16AM -0600, Eric W. Biederman wrote:
> Jamie Lokier <jamie.lokier@cern.ch> writes:
> 
> > > > [Aside: is there the possibility to have mincore return the "!accessed"
> > > > and "!dirty" bits of each page, perhaps as bits 1 and 2 of the returned
> > > > bytes?  I can imagine a bunch of garbage collection algorithms that
> > > > could make good use of those bits.  Currently some GC systems mprotect()
> > > > regions and unprotect them on SEGV -- simply reading the !dirty status
> > > > would obviously be much simpler and faster.]
> 
> Dirty kernel wise means the page needs to be swapped out. Clean kernel
> wise mean the page is in the swap cache, and hasn't been written
> since it was swapped in.

Worse than that, returning dirty status bits in mincore() just wouldn't 
work for threads.  mincore() is a valid optimisation when you just treat
it as a hint: if a page gets swapped out between calling mincore() and 
using the page, nothing breaks, you just get an extra page fault.  

The same is not true for the sort of garbage collection or distributed
memory mechanisms which use mprotect().  If you find that a page is clean
via mincore() and discard the data based on that, there is nothing to 
stop another thread from dirtying the data after the mincore() and losing
its modification.  mprotect() has the advantage of holding page table
locks so it can do an atomic read-modify-write on the page table entries.
Without that locking, you just can't reliably use dirty/accessed
information.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/