All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Baoquan He <bhe@redhat.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
	songmuchun@bytedance.com, akpm@linux-foundation.org,
	catalin.marinas@arm.com, will@kernel.org,
	anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] arm64/hugetlb: Implement arm64 specific hugetlb_mask_last_hp
Date: Thu, 16 Jun 2022 10:35:22 -0700	[thread overview]
Message-ID: <Yqtp2hA+5pRiFskC@monkey> (raw)
In-Reply-To: <Yqscbw0l9dL9Eldd@MiWiFi-R3L-srv>

On 06/16/22 20:05, Baoquan He wrote:
> On 06/16/22 at 11:34am, Baolin Wang wrote:
> > The HugeTLB address ranges are linearly scanned during fork, unmap and
> > remap operations, and the linear scan can skip to the end of range mapped
> > by the page table page if hitting a non-present entry, which can help
> > to speed linear scanning of the HugeTLB address ranges.
> > 
> > So hugetlb_mask_last_hp() is introduced to help to update the address in
> > the loop of HugeTLB linear scanning with getting the last huge page mapped
> > by the associated page table page[1], when a non-present entry is encountered.
> > 
> > Considering ARM64 specific cont-pte/pmd size HugeTLB, this patch implemented
> > an ARM64 specific hugetlb_mask_last_hp() to help this case.
> > 
> > [1] https://lore.kernel.org/linux-mm/20220527225849.284839-1-mike.kravetz@oracle.com/
> > 
> > Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> > ---
> > Note: this patch is based on the series: "hugetlb: speed up linear
> > address scanning" from Mike. Mike, please fold it into your series.
> > Thanks.
> > ---
> >  arch/arm64/mm/hugetlbpage.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index e2a5ec9..958935c 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -368,6 +368,26 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
> >  	return NULL;
> >  }
> >  
> > +unsigned long hugetlb_mask_last_hp(struct hstate *h)
> > +{
> > +	unsigned long hp_size = huge_page_size(h);
> 
> hp_size may not be a good name, it reminds me of hotplug. I would name
> it hpage_size even though a little more characters are added.
> 

How about just hugetlb_mask_last_page?  Since the routine is prefixed
with 'hugetlb' and we are passing in a pointer to a hstate, I think there
is enough context to know we are talking about a huge page mask as
opposed to a base page mask.

If OK, I will change the name in my patches and here.
-- 
Mike Kravetz

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Baoquan He <bhe@redhat.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
	songmuchun@bytedance.com, akpm@linux-foundation.org,
	catalin.marinas@arm.com, will@kernel.org,
	anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] arm64/hugetlb: Implement arm64 specific hugetlb_mask_last_hp
Date: Thu, 16 Jun 2022 10:35:22 -0700	[thread overview]
Message-ID: <Yqtp2hA+5pRiFskC@monkey> (raw)
In-Reply-To: <Yqscbw0l9dL9Eldd@MiWiFi-R3L-srv>

On 06/16/22 20:05, Baoquan He wrote:
> On 06/16/22 at 11:34am, Baolin Wang wrote:
> > The HugeTLB address ranges are linearly scanned during fork, unmap and
> > remap operations, and the linear scan can skip to the end of range mapped
> > by the page table page if hitting a non-present entry, which can help
> > to speed linear scanning of the HugeTLB address ranges.
> > 
> > So hugetlb_mask_last_hp() is introduced to help to update the address in
> > the loop of HugeTLB linear scanning with getting the last huge page mapped
> > by the associated page table page[1], when a non-present entry is encountered.
> > 
> > Considering ARM64 specific cont-pte/pmd size HugeTLB, this patch implemented
> > an ARM64 specific hugetlb_mask_last_hp() to help this case.
> > 
> > [1] https://lore.kernel.org/linux-mm/20220527225849.284839-1-mike.kravetz@oracle.com/
> > 
> > Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> > ---
> > Note: this patch is based on the series: "hugetlb: speed up linear
> > address scanning" from Mike. Mike, please fold it into your series.
> > Thanks.
> > ---
> >  arch/arm64/mm/hugetlbpage.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index e2a5ec9..958935c 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -368,6 +368,26 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
> >  	return NULL;
> >  }
> >  
> > +unsigned long hugetlb_mask_last_hp(struct hstate *h)
> > +{
> > +	unsigned long hp_size = huge_page_size(h);
> 
> hp_size may not be a good name, it reminds me of hotplug. I would name
> it hpage_size even though a little more characters are added.
> 

How about just hugetlb_mask_last_page?  Since the routine is prefixed
with 'hugetlb' and we are passing in a pointer to a hstate, I think there
is enough context to know we are talking about a huge page mask as
opposed to a base page mask.

If OK, I will change the name in my patches and here.
-- 
Mike Kravetz


  reply	other threads:[~2022-06-16 17:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16  3:34 [PATCH] arm64/hugetlb: Implement arm64 specific hugetlb_mask_last_hp Baolin Wang
2022-06-16  3:34 ` Baolin Wang
2022-06-16  8:47 ` kernel test robot
2022-06-16  8:47   ` kernel test robot
2022-06-16 10:50 ` kernel test robot
2022-06-16 10:50   ` kernel test robot
2022-06-16 12:05 ` Baoquan He
2022-06-16 12:05   ` Baoquan He
2022-06-16 17:35   ` Mike Kravetz [this message]
2022-06-16 17:35     ` Mike Kravetz
2022-06-17  0:53     ` Baoquan He
2022-06-17  0:53       ` Baoquan He
2022-06-17 12:17 ` kernel test robot
2022-06-17 12:17   ` kernel test robot
2022-06-18  3:25   ` Baolin Wang
2022-06-18  3:25     ` Baolin Wang
2022-06-18  3:25     ` Baolin Wang

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=Yqtp2hA+5pRiFskC@monkey \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=songmuchun@bytedance.com \
    --cc=will@kernel.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 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.