Re: [PATCH] THP: need is_vma_temporary_stack() when referencetransparent_hugepage_enabled

From: Andrea Arcangeli
Date: Wed May 02 2012 - 13:55:15 EST


On Wed, May 02, 2012 at 11:17:23AM +0800, Alex Shi wrote:
> On 05/01/2012 07:05 AM, Andrew Morton wrote:
>
> > On Sat, 28 Apr 2012 14:33:15 +0800
> > Alex Shi <alex.shi@xxxxxxxxx> wrote:
> >
> >> When the transparent_hugepage_enabled() used out of mm/,
> >> is_vma_temporary_stack() need be referenced. Otherwise, it has compile
> >> error.
> >
> > This is a poor changelog - it doesn't tell us how this compilation
> > error comes about. Is there some known build error in the mainline
> > kernel, or did you discover this when altering the kernel, or what?
>
> >
>
> > One of the several reasons for this information is to permit others to
> > work out which kernel version(s) should be fixed.
> >

I wanted to ask the same question.

> I am sorry for the unclear log!
> When I try to transparent_hugepage_enabled() in arch/x86/mm/tlb.c with
> huge_mm.h include: +#include <linux/huge_mm.h>. make give me the following
> error:

I already guessed it was for development code out of tree code but I
wasn't sure, thanks for the clarification.

> ...
> CC arch/x86/mm/srat.o
> arch/x86/mm/tlb.c: In function âflush_tlb_rangeâ:
> arch/x86/mm/tlb.c:324:4: error: implicit declaration of function âis_vma_temporary_stackâ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> ...
> Since it is not convenitant for user to include 2 head files just for one
> target function, I send this patch.
>
> > is_vma_temporary_stack() is already declared in rmap.h. We should not
> > declare it in two places.

My preference would still be to remove the is_vma_temporary_stack and
use two vmas during mremap of execve, that would remove the "vma"
parameter from transparent_hugepage_enabled() but others prefers to
skip a vma allocation in execve and stick to is_vma_temporary_stack,
which is fair enough argument.

> Oh, yes. Since is_vma_temporay_stack is just used in rmap.c and huge_memory.c
> . is it better to move it to huge_mm.h?

I guess it was cleaner on rmap.h as this is not related to THP, but
clearly it works better in huge_mm.h (and rmap.h->mm.h->huge_mm.h is
included automatically) so the patch looks fine to me.

Thanks,
Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/