On Fri, Jul 20, 2012 at 04:36:35PM +0200, Michal Hocko wrote: > And here is my attempt for the fix (Hugh mentioned something similar > earlier but he suggested using special flags in ptes or VMAs). I still > owe doc. update and it hasn't been tested with too many configs and I > could missed some definition updates. > I also think that changelog could be much better, I will add (steal) the > full bug description if people think that this way is worth going rather > than the one suggested by Mel. > To be honest I am not quite happy how I had to pollute generic mm code with > something that is specific to a single architecture. > Mel hammered it with the test case and it survived.
Tested-by: Mel Gorman <[email protected]> This approach looks more or less like what I was expecting. I like that the trick was applied to the page table page instead of using PTE tricks or by bodging it with a VMA flag like I was thinking so kudos for that. I also prefer this approach to trying to free the page tables on or near huge_pmd_unshare() In general I think this patch would execute better than mine because it is far less heavy-handed but I share your concern that it changes the core MM quite a bit for a corner case that only one architecture cares about. I am completely biased of course, but I still prefer my patch because other than an API change it keeps the bulk of the madness in arch/x86/mm/hugetlbpage.c . I am also not concerned with the scalability of how quickly we can setup page table sharing. Hugh, I'm afraid you get to choose :) -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
