Re: Extensions to mincore

[Jamie Lokier <jamie.lokier@cern.ch>]

Stephen C. Tweedie wrote:
> > You're right, that for GC the "!dirty" bit has to mean "since the last
> > time we called mincore".
> 
> And that information is not maintained anywhere.  In fact, it basically
> _can't_ be maintained, since the hardware only maintains one bit and
> we already use that dirty bit.  The only way round this is to use
> mprotect-style munging.

Didn't you read a few paragraphs down, where I explain how to implement
this?  You've got struct page.  It is enough for private mappings, and
we don't need this feature for shared mappings.

> > All threads sharing a page have to synchronise their mincore calls for
> > that page, but that situation is no different to the SEGV method: all
> > threads have to synchronise with the information collected from that,
> > too.
> 
> It's not about synchronising between mincore calls, it's about 
> synchronising mincore calls on one CPU with direct memory references
> modifying page tables on another CPU.

Note, for both GC synchronisation methods I described, the mincore()
call does not happen concurrently with other processors updating the
page flags.  In the first case all threads accessing the GC arena are
blocked, and in the second the entire area is write-protected during the
mincore() call.

So the synchronisation you say isn't possible isn't a required feature.
(I know it's quite easy on x86, but probably not some other CPUs).

It would be enough the say "the mincore accessed/dirty bits are not
guaranteed to be accurate if pages are accessed by concurrent threads
during the mincore call".

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