Hi Andrea, On Tue, Aug 01, 2017 at 09:33:41PM +0200, Andrea Arcangeli wrote: > Hello, > > On Tue, Aug 01, 2017 at 02:56:17PM +0900, Minchan Kim wrote: > > CPU0 CPU1 CPU2 CPU3 > > ---- ---- ---- ---- > > Write the same > > value on page > > > > [cache PTE as > > dirty in TLB] > > > > MADV_FREE > > pte_mkclean() > > > > 4 > clear_refs > > pte_wrprotect() > > > > write_protect_page() > > [ success, no flush ] > > > > pages_indentical() > > [ ok ] > > > > Write to page > > different value > > > > [Ok, using stale > > PTE] > > > > replace_page() > > > > Later, CPU1, CPU2 and CPU3 would flush the TLB, but that is too late. CPU0 > > already wrote on the page, but KSM ignored this write, and it got lost. > > " > > > > In above scenario, MADV_FREE is fixed by changing TLB batching API > > including [set|clear]_tlb_flush_pending. Remained thing is soft-dirty part. > > > > This patch changes soft-dirty uses TLB batching API instead of flush_tlb_mm > > and KSM checks pending TLB flush by using mm_tlb_flush_pending so that > > it will flush TLB to avoid data lost if there are other parallel threads > > pending TLB flush. > > > > [1] http://lkml.kernel.org/r/[email protected] > > > > Note: > > I failed to reproduce this problem through Nadav's test program which > > need to tune timing in my system speed so didn't confirm it work. > > Nadav, Could you test this patch on your test machine? > > Reviewed-by: Andrea Arcangeli <[email protected]>
Thanks for the review!
