linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Muchun Song <songmuchun@bytedance.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: mike.kravetz@oracle.com, david@redhat.com,
	akpm@linux-foundation.org, corbet@lwn.net, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 6/6] mm: hugetlb_vmemmap: improve hugetlb_vmemmap code readability
Date: Mon, 13 Jun 2022 17:01:43 +0800	[thread overview]
Message-ID: <Yqb89waW/jcsgRgo@FVFYT0MHHV2J.usts.net> (raw)
In-Reply-To: <Yqb2bA25HhLU/mpM@localhost.localdomain>

On Mon, Jun 13, 2022 at 10:33:48AM +0200, Oscar Salvador wrote:
> On Mon, Jun 13, 2022 at 02:35:12PM +0800, Muchun Song wrote:
> > -static __init int hugetlb_vmemmap_sysctls_init(void)
> > +static int __init hugetlb_vmemmap_init(void)
> >  {
> > +	const struct hstate *h;
> > +	bool optimizable = false;
> > +
> >  	/*
> > -	 * If "struct page" crosses page boundaries, the vmemmap pages cannot
> > -	 * be optimized.
> > +	 * There are only (RESERVE_VMEMMAP_SIZE / sizeof(struct page)) struct
> > +	 * page structs that can be used when HVO is enabled.
> >  	 */
> > -	if (is_power_of_2(sizeof(struct page)))
> > -		register_sysctl_init("vm", hugetlb_vmemmap_sysctls);
> > +	BUILD_BUG_ON(__NR_USED_SUBPAGE >= RESERVE_VMEMMAP_SIZE / sizeof(struct page));
> 
> I need to take another look, but from the first glance there is something
> here that caught my eye.
>

Thanks for taking a look. This is introduced in commit f41f2ed43ca5.
 
> > +
> > +	for_each_hstate(h) {
> > +		char buf[16];
> > +		unsigned int size = 0;
> > +
> > +		if (hugetlb_vmemmap_optimizable(h))
> > +			size = hugetlb_vmemmap_size(h) - RESERVE_VMEMMAP_SIZE;
> > +		optimizable = size ? true : optimizable;
> 
> This feels weird, just use false instead of optimizable.
>

This is a loop, we shoud keep "optimizable" as "true" as long as there is one
hstate is optimizable. How about:

  if (size)
	optimizable = true;

> > +		string_get_size(huge_page_size(h), 1, STRING_UNITS_2, buf,
> > +				sizeof(buf));
> > +		pr_info("%d KiB vmemmap can be optimized for a %s page\n",
> > +			size / SZ_1K, buf);
> 
> I do not have a strong opinion but I wonder whether this brings a lot.
>

I thought the users can know what size HugeTLB is optimizable via
this log.  E.g. On aarch64, 64KB HugeTLB cannot be optimizable.
I do not have a strong opinion as well, if anyone think it is
unnecessary, I'll drop it in next version.

Thanks.



  reply	other threads:[~2022-06-13  9:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-13  6:35 [PATCH 0/6] Simplify hugetlb vmemmap and improve its readability Muchun Song
2022-06-13  6:35 ` [PATCH 1/6] mm: hugetlb_vmemmap: delete hugetlb_optimize_vmemmap_enabled() Muchun Song
2022-06-13  8:04   ` Oscar Salvador
2022-06-13 18:15   ` Mike kravetz
2022-06-20 16:57   ` Catalin Marinas
2022-06-13  6:35 ` [PATCH 2/6] mm: hugetlb_vmemmap: optimize vmemmap_optimize_mode handling Muchun Song
2022-06-13  8:10   ` Oscar Salvador
2022-06-13  8:24     ` Muchun Song
2022-06-13 18:28   ` Mike kravetz
2022-06-13  6:35 ` [PATCH 3/6] mm: hugetlb_vmemmap: introduce the name HVO Muchun Song
2022-06-13  8:13   ` Oscar Salvador
2022-06-13 15:39   ` David Hildenbrand
2022-06-14  3:15     ` Muchun Song
2022-06-13 21:19   ` Mike Kravetz
2022-06-14  3:17     ` Muchun Song
2022-06-15 14:51   ` Joao Martins
2022-06-16  3:28     ` Muchun Song
2022-06-16 22:27       ` Mike Kravetz
2022-06-17  7:49         ` Muchun Song
2022-06-13  6:35 ` [PATCH 4/6] mm: hugetlb_vmemmap: move vmemmap code related to HugeTLB to hugetlb_vmemmap.c Muchun Song
2022-06-13  8:15   ` Oscar Salvador
2022-06-13 21:34   ` Mike Kravetz
2022-06-13  6:35 ` [PATCH 5/6] mm: hugetlb_vmemmap: replace early_param() with core_param() Muchun Song
2022-06-13 21:43   ` Mike Kravetz
2022-06-13  6:35 ` [PATCH 6/6] mm: hugetlb_vmemmap: improve hugetlb_vmemmap code readability Muchun Song
2022-06-13  8:33   ` Oscar Salvador
2022-06-13  9:01     ` Muchun Song [this message]
2022-06-14  0:22       ` Mike Kravetz
2022-06-14  4:17         ` Muchun Song
2022-06-14 16:57           ` Mike Kravetz
2022-06-15 12:33             ` Muchun Song

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=Yqb89waW/jcsgRgo@FVFYT0MHHV2J.usts.net \
    --to=songmuchun@bytedance.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=osalvador@suse.de \
    /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