All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zi Yan" <ziy@nvidia.com>
To: "David Hildenbrand" <david@redhat.com>
Cc: "Oscar Salvador" <osalvador@suse.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	x86@kernel.org, "Andy Lutomirski" <luto@kernel.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Anshuman Khandual" <anshuman.khandual@arm.com>,
	"Michal Hocko" <mhocko@suse.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Wei Yang" <richard.weiyang@linux.alibaba.com>,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size
Date: Thu, 06 May 2021 11:37:15 -0400	[thread overview]
Message-ID: <9D7FD316-988E-4B11-AC1C-64FF790BA79E@nvidia.com> (raw)
In-Reply-To: <fb60eabd-f8ef-2cb1-7338-7725efe3c286@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

On 6 May 2021, at 11:31, David Hildenbrand wrote:

> On 06.05.21 17:26, Zi Yan wrote:
>> From: Zi Yan <ziy@nvidia.com>
>>
>> Hi all,
>>
>> This patchset tries to remove the restriction on memory hotplug/hotremove
>> granularity, which is always greater or equal to memory section size[1].
>> With the patchset, kernel is able to online/offline memory at a size independent
>> of memory section size, as small as 2MB (the subsection size).
>
> ... which doesn't make any sense as we can only online/offline whole memory block devices.

Why limit the memory block size to section size? Patch 3 removes the restriction
by using (start_pfn, nr_pages) to allow memory block size goes below section size.
Also we have subsection bitmap available to tell us which subsection is online,
there is no reason to force memory block size to match section size.

>
>>
>> The motivation is to increase MAX_ORDER of the buddy allocator and pageblock
>> size without increasing memory hotplug/hotremove granularity at the same time,
>
> Gah, no. Please no. No.
>
>> so that the kernel can allocator 1GB pages using buddy allocator and utilizes
>> existing pageblock based anti-fragmentation, paving the road for 1GB THP
>> support[2].
>
> Not like this, please no.
>
>>
>> The patchset utilizes the existing subsection support[3] and changes the
>> section size alignment checks to subsection size alignment checks. There are
>> also changes to pageblock code to support partial pageblocks, when pageblock
>> size is increased along with MAX_ORDER. Increasing pageblock size can enable
>> kernel to utilize existing anti-fragmentation mechanism for gigantic page
>> allocations.
>
> Please not like this.
>
>>
>> The last patch increases SECTION_SIZE_BITS to demonstrate the use of memory
>> hotplug/hotremove subsection, but is not intended to be merged as is. It is
>> there in case one wants to try this out and will be removed during the final
>> submission.
>>
>> Feel free to give suggestions and comments. I am looking forward to your
>> feedback.
>
> Please not like this.

Do you mind sharing more useful feedback instead of just saying a lot of No?

Thanks.


—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Zi Yan" <ziy@nvidia.com>
To: "David Hildenbrand" <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>,
	linux-ia64@vger.kernel.org,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	x86@kernel.org, Dan Williams <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linuxppc-dev@lists.ozlabs.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>,
	Oscar Salvador <osalvador@suse.de>
Subject: Re: [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size
Date: Thu, 06 May 2021 11:37:15 -0400	[thread overview]
Message-ID: <9D7FD316-988E-4B11-AC1C-64FF790BA79E@nvidia.com> (raw)
In-Reply-To: <fb60eabd-f8ef-2cb1-7338-7725efe3c286@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

On 6 May 2021, at 11:31, David Hildenbrand wrote:

> On 06.05.21 17:26, Zi Yan wrote:
>> From: Zi Yan <ziy@nvidia.com>
>>
>> Hi all,
>>
>> This patchset tries to remove the restriction on memory hotplug/hotremove
>> granularity, which is always greater or equal to memory section size[1].
>> With the patchset, kernel is able to online/offline memory at a size independent
>> of memory section size, as small as 2MB (the subsection size).
>
> ... which doesn't make any sense as we can only online/offline whole memory block devices.

Why limit the memory block size to section size? Patch 3 removes the restriction
by using (start_pfn, nr_pages) to allow memory block size goes below section size.
Also we have subsection bitmap available to tell us which subsection is online,
there is no reason to force memory block size to match section size.

>
>>
>> The motivation is to increase MAX_ORDER of the buddy allocator and pageblock
>> size without increasing memory hotplug/hotremove granularity at the same time,
>
> Gah, no. Please no. No.
>
>> so that the kernel can allocator 1GB pages using buddy allocator and utilizes
>> existing pageblock based anti-fragmentation, paving the road for 1GB THP
>> support[2].
>
> Not like this, please no.
>
>>
>> The patchset utilizes the existing subsection support[3] and changes the
>> section size alignment checks to subsection size alignment checks. There are
>> also changes to pageblock code to support partial pageblocks, when pageblock
>> size is increased along with MAX_ORDER. Increasing pageblock size can enable
>> kernel to utilize existing anti-fragmentation mechanism for gigantic page
>> allocations.
>
> Please not like this.
>
>>
>> The last patch increases SECTION_SIZE_BITS to demonstrate the use of memory
>> hotplug/hotremove subsection, but is not intended to be merged as is. It is
>> there in case one wants to try this out and will be removed during the final
>> submission.
>>
>> Feel free to give suggestions and comments. I am looking forward to your
>> feedback.
>
> Please not like this.

Do you mind sharing more useful feedback instead of just saying a lot of No?

Thanks.


—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Zi Yan" <ziy@nvidia.com>
To: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	x86@kernel.org, Andy Lutomirski <luto@kernel.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Michal Hocko <mhocko@suse.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size
Date: Thu, 06 May 2021 15:37:15 +0000	[thread overview]
Message-ID: <9D7FD316-988E-4B11-AC1C-64FF790BA79E@nvidia.com> (raw)
In-Reply-To: <fb60eabd-f8ef-2cb1-7338-7725efe3c286@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

On 6 May 2021, at 11:31, David Hildenbrand wrote:

> On 06.05.21 17:26, Zi Yan wrote:
>> From: Zi Yan <ziy@nvidia.com>
>>
>> Hi all,
>>
>> This patchset tries to remove the restriction on memory hotplug/hotremove
>> granularity, which is always greater or equal to memory section size[1].
>> With the patchset, kernel is able to online/offline memory at a size independent
>> of memory section size, as small as 2MB (the subsection size).
>
> ... which doesn't make any sense as we can only online/offline whole memory block devices.

Why limit the memory block size to section size? Patch 3 removes the restriction
by using (start_pfn, nr_pages) to allow memory block size goes below section size.
Also we have subsection bitmap available to tell us which subsection is online,
there is no reason to force memory block size to match section size.

>
>>
>> The motivation is to increase MAX_ORDER of the buddy allocator and pageblock
>> size without increasing memory hotplug/hotremove granularity at the same time,
>
> Gah, no. Please no. No.
>
>> so that the kernel can allocator 1GB pages using buddy allocator and utilizes
>> existing pageblock based anti-fragmentation, paving the road for 1GB THP
>> support[2].
>
> Not like this, please no.
>
>>
>> The patchset utilizes the existing subsection support[3] and changes the
>> section size alignment checks to subsection size alignment checks. There are
>> also changes to pageblock code to support partial pageblocks, when pageblock
>> size is increased along with MAX_ORDER. Increasing pageblock size can enable
>> kernel to utilize existing anti-fragmentation mechanism for gigantic page
>> allocations.
>
> Please not like this.
>
>>
>> The last patch increases SECTION_SIZE_BITS to demonstrate the use of memory
>> hotplug/hotremove subsection, but is not intended to be merged as is. It is
>> there in case one wants to try this out and will be removed during the final
>> submission.
>>
>> Feel free to give suggestions and comments. I am looking forward to your
>> feedback.
>
> Please not like this.

Do you mind sharing more useful feedback instead of just saying a lot of No?

Thanks.


—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

  reply	other threads:[~2021-05-06 15:38 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 15:26 [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size Zi Yan
2021-05-06 15:26 ` Zi Yan
2021-05-06 15:26 ` Zi Yan
2021-05-06 15:26 ` [RFC PATCH 1/7] mm: sparse: set/clear subsection bitmap when pages are onlined/offlined Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 17:48   ` David Hildenbrand
2021-05-06 17:48     ` David Hildenbrand
2021-05-06 17:48     ` David Hildenbrand
2021-05-06 19:03     ` Zi Yan
2021-05-06 19:03       ` Zi Yan
2021-05-06 19:03       ` Zi Yan
2021-05-06 19:14       ` David Hildenbrand
2021-05-06 19:14         ` David Hildenbrand
2021-05-06 19:14         ` David Hildenbrand
2021-05-06 15:26 ` [RFC PATCH 2/7] mm: set pageblock_order to the max of HUGETLB_PAGE_ORDER and MAX_ORDER-1 Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26 ` [RFC PATCH 3/7] mm: memory_hotplug: decouple memory_block size with section size Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26 ` [RFC PATCH 4/7] mm: pageblock: allow set/unset migratetype for partial pageblock Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26 ` [RFC PATCH 5/7] mm: memory_hotplug, sparse: enable memory hotplug/hotremove subsections Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26 ` [RFC PATCH 6/7] arch: x86: no MAX_ORDER exceeds SECTION_SIZE check for 32bit vdso Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26 ` [RFC PATCH 7/7] [not for merge] mm: increase SECTION_SIZE_BITS to 31 Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:26   ` Zi Yan
2021-05-06 15:31 ` [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size David Hildenbrand
2021-05-06 15:31   ` David Hildenbrand
2021-05-06 15:31   ` David Hildenbrand
2021-05-06 15:37   ` Zi Yan [this message]
2021-05-06 15:37     ` Zi Yan
2021-05-06 15:37     ` Zi Yan
2021-05-06 15:40     ` David Hildenbrand
2021-05-06 15:40       ` David Hildenbrand
2021-05-06 15:40       ` David Hildenbrand
2021-05-06 15:50       ` Zi Yan
2021-05-06 15:50         ` Zi Yan
2021-05-06 15:50         ` Zi Yan
2021-05-06 16:28         ` David Hildenbrand
2021-05-06 16:28           ` David Hildenbrand
2021-05-06 16:28           ` David Hildenbrand
2021-05-06 18:49           ` Zi Yan
2021-05-06 18:49             ` Zi Yan
2021-05-06 18:49             ` Zi Yan
2021-05-06 19:10             ` David Hildenbrand
2021-05-06 19:10               ` David Hildenbrand
2021-05-06 19:10               ` David Hildenbrand
2021-05-06 19:30               ` Matthew Wilcox
2021-05-06 19:30                 ` Matthew Wilcox
2021-05-06 19:30                 ` Matthew Wilcox
2021-05-06 19:38                 ` David Hildenbrand
2021-05-06 19:38                   ` David Hildenbrand
2021-05-06 19:38                   ` David Hildenbrand
2021-05-06 15:38   ` David Hildenbrand
2021-05-06 15:38     ` David Hildenbrand
2021-05-06 15:38     ` David Hildenbrand
2021-05-07 11:55   ` Michal Hocko
2021-05-07 11:55     ` Michal Hocko
2021-05-07 11:55     ` Michal Hocko
2021-05-07 14:00     ` David Hildenbrand
2021-05-07 14:00       ` David Hildenbrand
2021-05-07 14:00       ` David Hildenbrand
2021-05-10 14:36       ` Zi Yan
2021-05-10 14:36         ` Zi Yan
2021-05-10 14:36         ` Zi Yan
2021-05-12 16:14         ` David Hildenbrand
2021-05-12 16:14           ` David Hildenbrand
2021-05-12 16:14           ` David Hildenbrand
2021-06-02 15:56         ` Zi Yan
2021-06-02 15:56           ` Zi Yan
2021-06-14 11:32           ` David Hildenbrand
2021-06-14 11:32             ` David Hildenbrand
2021-06-14 11:32             ` David Hildenbrand
2021-05-06 15:42 ` Zi Yan
2021-05-06 15:42   ` Zi Yan
2021-05-06 15:42   ` Zi Yan

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=9D7FD316-988E-4B11-AC1C-64FF790BA79E@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=osalvador@suse.de \
    --cc=rafael@kernel.org \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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.