From: "Li Xinhai" <lixinhai.lxh@gmail.com>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "Mike Kravetz" <mike.kravetz@oracle.com>,
akpm <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm/hugetlb: avoid unnecessary check on pud and pmd entry in huge_pte_offset
Date: Thu, 23 Apr 2020 21:12:23 +0800 [thread overview]
Message-ID: <202004232112215571429@gmail.com> (raw)
In-Reply-To: 1587646154-26276-1-git-send-email-lixinhai.lxh@gmail.com
On 2020-04-23 at 20:49 Li Xinhai wrote:
>When huge_pte_offset() is called, the parameter sz can only be PUD_SIZE
>or PMD_SIZE.
>If sz is PUD_SIZE and code can reach pud, then *pud must be none, or
>normal hugetlb entry, or non-present (migration or hwpoisoned) hugetlb
>entry, and we can directly return pud.
>When sz is PMD_SIZE, pud must be none or present, and if code can reach
>pmd, we can directly return pmd.
>
>So, after this patch, the code is simplified by first check on the
>parameter sz, and avoid unnecessary checks in current code.
>
>Signed-off-by: Li Xinhai <lixinhai.lxh@gmail.com>
>Cc: Mike Kravetz <mike.kravetz@oracle.com>
>Cc: Andrew Morton <akpm@linux-foundation.org>
Since this huge_pte_offset() is under CONFIG_ARCH_WANT_GENERAL_HUGETLB,
I only have chance to test with x86_64, but the logical should hold for all other
cases which using this general implementation.
The exsiting code path was introduced by commit 9b19df292c6 (mm/hugetlb.c:
make huge_pte_offset() consistent and document behaviour), and the sematics
is maintained after current patch applied.
next prev parent reply other threads:[~2020-04-23 13:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 12:49 [PATCH] mm/hugetlb: avoid unnecessary check on pud and pmd entry in huge_pte_offset Li Xinhai
2020-04-23 13:12 ` Li Xinhai [this message]
2020-04-23 18:14 ` Mike Kravetz
2020-04-23 18:38 ` Jason Gunthorpe
2020-04-24 4:07 ` Li Xinhai
2020-04-24 12:57 ` Jason Gunthorpe
2020-04-24 13:33 ` Li Xinhai
2020-04-24 13:42 ` Jason Gunthorpe
2020-04-24 14:07 ` Li Xinhai
2020-04-24 14:10 ` Jason Gunthorpe
2020-04-24 14:53 ` Li Xinhai
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=202004232112215571429@gmail.com \
--to=lixinhai.lxh@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.