On Mon, 2013-12-09 at 14:17 +0800, Liu ping fan wrote: > On Mon, Dec 9, 2013 at 8:31 AM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > On Thu, 2013-12-05 at 16:23 +0530, Aneesh Kumar K.V wrote: > >> Liu Ping Fan <kernelf...@gmail.com> writes: > >> > >> > To enable the do_numa_page(), we should not fix _PAGE_NUMA in > >> > hash_page(), so bail out for the case of pte_numa(). > > > > For some reason I don't have 2/3 and 3/3 in my mbox (though I do have > > them on patchwork) so I'll reply to this one. > > > > Overall, your statement that this is a faster path needs to be backed up > > with numbers. > > > > The code is complicated enough as it-is, such additional mess in the low > > level hashing code requires a good justification, and also a > > demonstration that it doesn't add overhead to the normal hash path. > > > For the test, is it ok to have an user application to copy page where > all page are PG_mlocked?
If that specific scenario is relevant in practice, then yes, though also demonstrate the lack of regression with some more normal path such as a kernel compile. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
