All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Muchun Song <songmuchun@bytedance.com>
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 2/6] mm: hugetlb_vmemmap: optimize vmemmap_optimize_mode handling
Date: Mon, 13 Jun 2022 10:10:08 +0200	[thread overview]
Message-ID: <Yqbw4IYwtLQaoarB@localhost.localdomain> (raw)
In-Reply-To: <20220613063512.17540-3-songmuchun@bytedance.com>

On Mon, Jun 13, 2022 at 02:35:08PM +0800, Muchun Song wrote:
> We hold an another reference to hugetlb_optimize_vmemmap_key when
> making vmemmap_optimize_mode on, because we use static_key to tell
> memory_hotplug that memory_hotplug.memmap_on_memory should be
> overridden.  However, this rule has gone when we have introduced
> SECTION_CANNOT_OPTIMIZE_VMEMMAP.  Therefore, we could simplify
> vmemmap_optimize_mode handling by not holding an another reference
> to hugetlb_optimize_vmemmap_key.
> 
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>

LGTM, and it looks way nicer, so

Reviewed-by: Oscar Salvador <osalvador@suse.de>

One question below though

> -static enum vmemmap_optimize_mode vmemmap_optimize_mode =
> +static bool vmemmap_optimize_enabled =
>  	IS_ENABLED(CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON);

So, by default vmemmap_optimize_enabled will be on if we have
CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON, but we can always override that
via cmdline, as below, right?


>  
> -static void vmemmap_optimize_mode_switch(enum vmemmap_optimize_mode to)
> -{
> -	if (vmemmap_optimize_mode == to)
> -		return;
> -
> -	if (to == VMEMMAP_OPTIMIZE_OFF)
> -		static_branch_dec(&hugetlb_optimize_vmemmap_key);
> -	else
> -		static_branch_inc(&hugetlb_optimize_vmemmap_key);
> -	WRITE_ONCE(vmemmap_optimize_mode, to);
> -}
> -
>  static int __init hugetlb_vmemmap_early_param(char *buf)
>  {
> -	bool enable;
> -	enum vmemmap_optimize_mode mode;
> -
> -	if (kstrtobool(buf, &enable))
> -		return -EINVAL;
> -
> -	mode = enable ? VMEMMAP_OPTIMIZE_ON : VMEMMAP_OPTIMIZE_OFF;
> -	vmemmap_optimize_mode_switch(mode);
> -
> -	return 0;
> +	return kstrtobool(buf, &vmemmap_optimize_enabled);
>  }
>  early_param("hugetlb_free_vmemmap", hugetlb_vmemmap_early_param);
>  
> @@ -103,7 +76,7 @@ static unsigned int optimizable_vmemmap_pages(struct hstate *h,
>  	unsigned long pfn = page_to_pfn(head);
>  	unsigned long end = pfn + pages_per_huge_page(h);
>  
> -	if (READ_ONCE(vmemmap_optimize_mode) == VMEMMAP_OPTIMIZE_OFF)
> +	if (!READ_ONCE(vmemmap_optimize_enabled))
>  		return 0;
>  
>  	for (; pfn < end; pfn += PAGES_PER_SECTION) {
> @@ -155,7 +128,6 @@ void __init hugetlb_vmemmap_init(struct hstate *h)
>  
>  	if (!is_power_of_2(sizeof(struct page))) {
>  		pr_warn_once("cannot optimize vmemmap pages because \"struct page\" crosses page boundaries\n");
> -		static_branch_disable(&hugetlb_optimize_vmemmap_key);
>  		return;
>  	}
>  
> @@ -176,36 +148,13 @@ void __init hugetlb_vmemmap_init(struct hstate *h)
>  }
>  
>  #ifdef CONFIG_PROC_SYSCTL
> -static int hugetlb_optimize_vmemmap_handler(struct ctl_table *table, int write,
> -					    void *buffer, size_t *length,
> -					    loff_t *ppos)
> -{
> -	int ret;
> -	enum vmemmap_optimize_mode mode;
> -	static DEFINE_MUTEX(sysctl_mutex);
> -
> -	if (write && !capable(CAP_SYS_ADMIN))
> -		return -EPERM;
> -
> -	mutex_lock(&sysctl_mutex);
> -	mode = vmemmap_optimize_mode;
> -	table->data = &mode;
> -	ret = proc_dointvec_minmax(table, write, buffer, length, ppos);
> -	if (write && !ret)
> -		vmemmap_optimize_mode_switch(mode);
> -	mutex_unlock(&sysctl_mutex);
> -
> -	return ret;
> -}
> -
>  static struct ctl_table hugetlb_vmemmap_sysctls[] = {
>  	{
>  		.procname	= "hugetlb_optimize_vmemmap",
> -		.maxlen		= sizeof(enum vmemmap_optimize_mode),
> +		.data		= &vmemmap_optimize_enabled,
> +		.maxlen		= sizeof(int),
>  		.mode		= 0644,
> -		.proc_handler	= hugetlb_optimize_vmemmap_handler,
> -		.extra1		= SYSCTL_ZERO,
> -		.extra2		= SYSCTL_ONE,
> +		.proc_handler	= proc_dobool,
>  	},
>  	{ }
>  };
> -- 
> 2.11.0
> 
> 

-- 
Oscar Salvador
SUSE Labs

  reply	other threads:[~2022-06-13  8:11 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 [this message]
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
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=Yqbw4IYwtLQaoarB@localhost.localdomain \
    --to=osalvador@suse.de \
    --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=songmuchun@bytedance.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.