From: Andrew Morton <akpm@linux-foundation.org>
To: Steve Capper <steve.capper@linaro.org>
Cc: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
catalin.marinas@arm.com
Subject: Re: [RESEND PATCH] mm: hugetlb: Introduce huge_pte_{page,present,young}
Date: Mon, 17 Mar 2014 15:07:30 -0700 [thread overview]
Message-ID: <20140317150730.156a3325ff96dfc6e1352902@linux-foundation.org> (raw)
In-Reply-To: <1395082318-7703-1-git-send-email-steve.capper@linaro.org>
On Mon, 17 Mar 2014 18:51:58 +0000 Steve Capper <steve.capper@linaro.org> wrote:
> Introduce huge pte versions of pte_page, pte_present and pte_young.
> This allows ARM (without LPAE) to use alternative pte processing logic
> for huge ptes.
>
> Where these functions are not defined by architectural code they
> fallback to the standard functions.
>
> Signed-off-by: Steve Capper <steve.capper@linaro.org>
> ---
> Hi,
> I'm resending this patch to provoke some discussion.
>
> We already have some huge_pte_ style functions, and this patch adds a
> few more (that simplify to the pte_ equivalents where unspecified).
>
> Having separate hugetlb versions of pte_page, present and mkyoung
> allows for a greatly simplified huge page implementation for ARM with
> the classical MMU (which has a different bit layout for huge ptes).
Looks OK to me. One thing...
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -353,6 +353,18 @@ static inline pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
> }
> #endif
>
> +#ifndef huge_pte_page
> +#define huge_pte_page(pte) pte_page(pte)
> +#endif
This #ifndef x #define x thing works well, but it is 100% unclear which
arch header file is supposed to define x if it wishes to override the
definition. We've had problems with that in the past where different
architectures put it in different files and various breakages ensued.
So can we decide which arch header file is responsible for defining
these, then document that right here in a comment and add an explicit
#include <asm/that-file.h>?
> +#ifndef huge_pte_present
> +#define huge_pte_present(pte) pte_present(pte)
> +#endif
> +
> +#ifndef huge_pte_mkyoung
> +#define huge_pte_mkyoung(pte) pte_mkyoung(pte)
> +#endif
> +
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-03-17 22:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-17 18:51 Steve Capper
2014-03-17 22:07 ` Andrew Morton [this message]
2014-03-20 9:50 ` Steve Capper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140317150730.156a3325ff96dfc6e1352902@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=steve.capper@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox