Re: [RFC/PATH 1/2] MM: Make Page Tables Relocatable -- conditional flush

["Ross Biro" <rossb@google.com>]

On Wed, Apr 30, 2008 at 3:56 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>>> - How does it deal with migrating the accessed/dirty bits in ptes if
>>>  cpus can be using old versions of the pte for a while after the
>>>  copy?  Losing dirty updates can lose data, so explicitly addressing
>>>  this point in code and/or comments is important.
>>>
>>
>> It doesn't currently.  Although it's easy to fix.  Just before the
>> free, we just have to copy the dirty bits again.  Slow, but not in a
>> critical path.
>>
>
> But the issue I'm concerned about is what happens if a process writes the
> page, causing its cpu to mark the (old, in-limbo) pte dirty.  Meanwhile
> someone else is scanning the pagetables looking for things to evict.  It
> check the (shiny new) pte, finds it not dirty, and decides to evict the
> apparently clean page.
>
> What, for that matter, stops a page from being evicted from under a limboed
> mapping?  Does it get accounted for (I guess the existing tlb flushing
> should be sufficient to keep it under control).

The delimbo functions can be extended to deal with the dirty bit.
They already have to be called to make sure the cpu is looking at the
proper page flags.  The easiest solution to the races is probably to
make the delimbo pte functions flush the tlb cache to make sure the
cpu will also be looking at the correct entry to update flags.
Otherwise the atomic ptep* functions would probably need to be
modified.

    Ross

--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>