linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Zi Yan <ziy@nvidia.com>, 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>,
	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: Fri, 7 May 2021 13:55:24 +0200	[thread overview]
Message-ID: <YJUqrOacyqI+kiKW@dhcp22.suse.cz> (raw)
In-Reply-To: <fb60eabd-f8ef-2cb1-7338-7725efe3c286@redhat.com>

[I haven't read through respective patches due to lack of time but let
 me comment on the general idea and the underlying justification]

On Thu 06-05-21 17:31:09, 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.

Agreed. The subsection thingy is just a hack to workaround pmem
alignement problems. For the real memory hotplug it is quite hard to
argue for reasonable hotplug scenarios for very small physical memory
ranges wrt. to the existing sparsemem memory model.
 
> > 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.

Agreed. Those are completely independent concepts. MAX_ORDER is can be
really arbitrary irrespective of the section size with vmemmap sparse
model. The existing restriction is due to old sparse model not being
able to do page pointer arithmetic across memory sections. Is there any
reason to stick with that memory model for an advance feature you are
working on?
-- 
Michal Hocko
SUSE Labs


  parent reply	other threads:[~2021-05-07 11:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 17:48   ` David Hildenbrand
2021-05-06 19:03     ` Zi Yan
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 ` [RFC PATCH 3/7] mm: memory_hotplug: decouple memory_block size with section size 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 ` [RFC PATCH 5/7] mm: memory_hotplug, sparse: enable memory hotplug/hotremove subsections 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 ` [RFC PATCH 7/7] [not for merge] mm: increase SECTION_SIZE_BITS to 31 Zi Yan
2021-05-06 15:31 ` [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size David Hildenbrand
2021-05-06 15:37   ` Zi Yan
2021-05-06 15:40     ` David Hildenbrand
2021-05-06 15:50       ` Zi Yan
2021-05-06 16:28         ` David Hildenbrand
2021-05-06 18:49           ` Zi Yan
2021-05-06 19:10             ` David Hildenbrand
2021-05-06 19:30               ` Matthew Wilcox
2021-05-06 19:38                 ` David Hildenbrand
2021-05-06 15:38   ` David Hildenbrand
2021-05-07 11:55   ` Michal Hocko [this message]
2021-05-07 14:00     ` David Hildenbrand
2021-05-10 14:36       ` Zi Yan
2021-05-12 16:14         ` David Hildenbrand
2021-06-02 15:56         ` Zi Yan
2021-06-14 11:32           ` David Hildenbrand
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=YJUqrOacyqI+kiKW@dhcp22.suse.cz \
    --to=mhocko@suse.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=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 \
    --cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox