On Mon, Dec 09, 2013 at 04:00:24PM +0000, Christoph Lameter wrote: > On Fri, 6 Dec 2013, Rik van Riel wrote: > > > > Ok then what are you trying to fix? > > > > It would help if you had actually read the patch. > > I read the patch. Please update the documentation to accurately describe > the race. > > From what I can see this race affects only huge pages and the basic issue > seems to be that huge pages do not use migration entries but directly > replace the pmd (migrate_misplaced_transhuge_page() f.e.). > I looked at what would be required to implement migration entry support for PMDs. It's major surgery because we do not have something like swap-like entries to use at that page table level. It looked like it would require inserting a fake entry (easiest would be to point to a global page) that all page table walkers would recognise, blocking on it and teaching every page table walker to get it right. One can't do something simple like clear the entry out because then the no page handlers for GUP or faults insert the zero page behind and it goes to hell and we can't hold the page table lock across the migration copy. > That is not safe and there may be multiple other races as we add more > general functionality to huge pages. An intermediate stage is needed > that allows the clearing out of remote tlb entries before the new tlb > entry becomes visible. > The patch flushes the TLBs as it is and future accesses are help up in the NUMA hinting fault handler. It's functionally similar to having a migration entry albeit it is special cased to handle just automatic NUMA balancing -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>