From: Muchun Song <muchun.song@linux.dev>
To: Mike Rapoport <rppt@kernel.org>
Cc: Usama Arif <usama.arif@bytedance.com>,
Linux-MM <linux-mm@kvack.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
linux-kernel@vger.kernel.org,
Muchun Song <songmuchun@bytedance.com>,
fam.zheng@bytedance.com, liangma@liangbit.com,
punit.agrawal@bytedance.com
Subject: Re: [v3 3/4] memblock: introduce MEMBLOCK_RSRV_NOINIT_VMEMMAP flag
Date: Mon, 28 Aug 2023 17:18:23 +0800 [thread overview]
Message-ID: <AAF485D2-508B-4F96-862F-3658104E8F76@linux.dev> (raw)
In-Reply-To: <20230828090941.GD3223@kernel.org>
> On Aug 28, 2023, at 17:09, Mike Rapoport <rppt@kernel.org> wrote:
>
> On Mon, Aug 28, 2023 at 04:52:10PM +0800, Muchun Song wrote:
>>
>>
>> On 2023/8/28 15:47, Mike Rapoport wrote:
>>> On Fri, Aug 25, 2023 at 12:18:35PM +0100, Usama Arif wrote:
>>>> For reserved memory regions marked with this flag,
>>>> reserve_bootmem_region is not called during memmap_init_reserved_pages.
>>>> This can be used to avoid struct page initialization for
>>>> regions which won't need them, for e.g. hugepages with
>>>> HVO enabled.
>>>>
>>>> Signed-off-by: Usama Arif <usama.arif@bytedance.com>
>>>> ---
>>>> include/linux/memblock.h | 10 ++++++++++
>>>> mm/memblock.c | 32 +++++++++++++++++++++++++++-----
>>>> 2 files changed, 37 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>>>> index f71ff9f0ec81..6d681d053880 100644
>>>> --- a/include/linux/memblock.h
>>>> +++ b/include/linux/memblock.h
>>>> @@ -40,6 +40,8 @@ extern unsigned long long max_possible_pfn;
>>>> * via a driver, and never indicated in the firmware-provided memory map as
>>>> * system RAM. This corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED in the
>>>> * kernel resource tree.
>>>> + * @MEMBLOCK_RSRV_NOINIT_VMEMMAP: memory region for which struct pages are
>>>> + * not initialized (only for reserved regions).
>>>> */
>>>> enum memblock_flags {
>>>> MEMBLOCK_NONE = 0x0, /* No special request */
>>>> @@ -47,6 +49,8 @@ enum memblock_flags {
>>>> MEMBLOCK_MIRROR = 0x2, /* mirrored region */
>>>> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */
>>>> MEMBLOCK_DRIVER_MANAGED = 0x8, /* always detected via a driver */
>>>> + /* don't initialize struct pages associated with this reserver memory block */
>>>> + MEMBLOCK_RSRV_NOINIT_VMEMMAP = 0x10,
>>> The flag means that struct page shouldn't be initialized, it may be used
>>> not only by vmemmap optimizations.
>>> Please drop _VMEMMAP.
>>
>> The area at where the struct pages located is vmemmap, I think the
>> "vmemap" suffix does not mean that it is for "vmemmap optimization",
>> it could specify the target which will not be initialized. For me,
>> MEMBLOCK_RSRV_NOINIT does not tell me what should not be initialized,
>> memblock itself or its struct page (aka vmemmap pages)? So maybe
>> the suffix is better to keep?
> In general case the area is memmap rather than vmemmap, so a better suffix
Right. memmap
> then would be _MEMMAP. I'm not too fond of that either, but I cannot think
> of better name.
I have no strong opinion, if we cannot think a better name, just drop the
suffix as you suggested and let the comments more specified. :-)
Thanks.
next prev parent reply other threads:[~2023-08-28 9:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-25 11:18 [v3 0/4] mm: hugetlb: Skip initialization of gigantic tail struct pages if freed by HVO Usama Arif
2023-08-25 11:18 ` [v3 1/4] mm: hugetlb_vmemmap: Use nid of the head page to reallocate it Usama Arif
2023-08-28 7:15 ` Muchun Song
2023-08-28 18:25 ` Mike Kravetz
2023-08-25 11:18 ` [v3 2/4] memblock: pass memblock_type to memblock_setclr_flag Usama Arif
2023-08-28 7:16 ` Muchun Song
2023-08-28 7:37 ` Mike Rapoport
2023-08-28 18:39 ` Mike Kravetz
2023-08-25 11:18 ` [v3 3/4] memblock: introduce MEMBLOCK_RSRV_NOINIT_VMEMMAP flag Usama Arif
2023-08-28 7:26 ` Muchun Song
2023-08-28 7:47 ` Mike Rapoport
2023-08-28 8:52 ` Muchun Song
2023-08-28 9:09 ` Mike Rapoport
2023-08-28 9:18 ` Muchun Song [this message]
2023-08-25 11:18 ` [v3 4/4] mm: hugetlb: Skip initialization of gigantic tail struct pages if freed by HVO Usama Arif
2023-08-28 11:33 ` Muchun Song
2023-08-28 21:04 ` Mike Kravetz
2023-08-29 3:33 ` Muchun Song
2023-08-29 3:47 ` Mike Kravetz
2023-08-30 10:27 ` [External] " Usama Arif
2023-08-31 6:21 ` [External] " Muchun Song
2023-08-31 9:58 ` Mel Gorman
2023-08-31 10:01 ` Muchun Song
2023-08-31 10:28 ` Mel Gorman
2023-08-31 7:33 ` [External] " Mike Rapoport
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=AAF485D2-508B-4F96-862F-3658104E8F76@linux.dev \
--to=muchun.song@linux.dev \
--cc=fam.zheng@bytedance.com \
--cc=liangma@liangbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=punit.agrawal@bytedance.com \
--cc=rppt@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=usama.arif@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.