Re: [PATCH RFC 1/1] numa: fix /proc//numa_maps for THP

Gerald Schaefer
2016-02-08T19:05:55Z

On Fri, 5 Feb 2016 17:03:17 +0100
Gerald Schaefer <gerald.schaefer@de.ibm.com> wrote:

> On Fri, 5 Feb 2016 07:38:09 -0800
> Dave Hansen <dave.hansen@intel.com> wrote:
>
> > On 02/05/2016 07:34 AM, Gerald Schaefer wrote:
> > > +static struct page *can_gather_numa_stats_pmd(pmd_t pmd,
> > > + struct vm_area_struct *vma,
> > > + unsigned long addr)
> > > +{
> >
> > Is there a way to do this without making a copy of most of
> > can_gather_numa_stats()? Seems like the kind of thing where the pmd
> > version will bitrot.
> >
>
> Yes, that also gave me a little headache, even more with the vm_normal_page()
> code duplication, but I didn't see a much better way. Separate _pte/_pmd
> functions that largely do the same thing seem not so uncommon to me.
>
> The best I could think of would be splitting the !HAVE_PTE_SPECIAL path
> in vm_normal_page() into a separate function, but I see not much room for
> improvement for can_gather_numa_stats(), other than maybe not having
> a _pmd version at all and doing all the work inside gather_pte_stats(),
> but that would probably just relocate the code duplication.

Nope, can't see any sane way to prevent the (trivial) code duplication in
can_gather_numa_stats_pmd(). Adding a "common" function for _pte and _pmd
handling (using void *) would be very ugly and given that the duplicated
code is just trivial sanity checks it also seems very disproportionate.
BTW, we also (should) have no "pmd version bitrot" in the countless other
places where we have separate _pte/_pmd versions.

So, any ideas or feedback on the vm_normal_page(_pmd) part?