linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 4/8] mm,memory_hotplug: Allocate memmap from the added memory range
Date: Wed, 21 Apr 2021 10:39:16 +0200	[thread overview]
Message-ID: <YH/ktDG/9o2OHNGj@dhcp22.suse.cz> (raw)
In-Reply-To: <20210421081546.GD22456@linux>

On Wed 21-04-21 10:15:46, Oscar Salvador wrote:
> On Tue, Apr 20, 2021 at 12:56:03PM +0200, Michal Hocko wrote:
[...]
> > necessary. Using two different iteration styles is also hurting the code
> > readability. I would go with the following
> > 	for (pfn = start_pfn; pfn < end_pfn; ) {
> > 		unsigned long order = min(MAX_ORDER - 1UL, __ffs(pfn));
> > 
> > 		while (start + (1UL << order) > end_pfn)
> >                         order--;
> > 		(*online_page_callback)(pfn_to_page(pfn), pageblock_order);
> > 		pfn += 1 << order;
> > 	}
> > 
> > which is what __free_pages_memory does already.
> 
> this is kinda what I used to have in the early versions, but it was agreed
> with David to split it in two loops to make it explicit.
> I can go back to that if it is preferred.

Not that I would insist but I find it better to use common constructs
when it doesn't hurt readability. The order evaluation can be even done
in a trivial helper.

> > > +	if (memmap_on_memory) {
> > > +		nr_vmemmap_pages = walk_memory_blocks(start, size, NULL,
> > > +						      get_nr_vmemmap_pages_cb);
> > > +		if (nr_vmemmap_pages) {
> > > +			if (size != memory_block_size_bytes()) {
> > > +				pr_warn("Refuse to remove %#llx - %#llx,"
> > > +					"wrong granularity\n",
> > > +					start, start + size);
> > > +				return -EINVAL;
> > > +			}
> > > +
> > > +			/*
> > > +			 * Let remove_pmd_table->free_hugepage_table do the
> > > +			 * right thing if we used vmem_altmap when hot-adding
> > > +			 * the range.
> > > +			 */
> > > +			mhp_altmap.alloc = nr_vmemmap_pages;
> > > +			altmap = &mhp_altmap;
> > > +		}
> > > +	}
> > > +
> > >  	/* remove memmap entry */
> > >  	firmware_map_remove(start, start + size, "System RAM");
> > 
> > I have to say I still dislike this and I would just wrap it inside out
> > and do the operation from within walk_memory_blocks but I will not
> > insist.
> 
> I have to confess I forgot about the details of that dicussion, as we were
> quite focused on decoupling vmemmap pages from {online,offline} interface.
> Would you mind elaborating a bit more?

As I've said I will not insist and this can be done in the follow up.
You are iterating over memory blocks just to refuse to do an operation
which can be split to several memory blocks. See
http://lkml.kernel.org/r/YFtPxH0CT5QZsnR1@dhcp22.suse.cz and follow
walk_memory_blocks(start, size, NULL, remove_memory_block_cb)
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2021-04-21  8:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210416112411.9826-1-osalvador@suse.de>
2021-04-16 11:24 ` [PATCH v9 1/8] drivers/base/memory: Introduce memory_block_{online,offline} Oscar Salvador
2021-04-20  9:23   ` Michal Hocko
2021-04-16 11:24 ` [PATCH v9 2/8] mm,memory_hotplug: Relax fully spanned sections check Oscar Salvador
2021-04-20  9:40   ` Michal Hocko
2021-04-21  7:37     ` Oscar Salvador
2021-04-16 11:24 ` [PATCH v9 3/8] mm,memory_hotplug: Factor out adjusting present pages into adjust_present_page_count() Oscar Salvador
2021-04-20  9:45   ` Michal Hocko
2021-04-21  8:00     ` Oscar Salvador
2021-04-21  8:06       ` David Hildenbrand
2021-04-21  8:31       ` Michal Hocko
2021-04-21  8:35         ` Oscar Salvador
2021-04-16 11:24 ` [PATCH v9 4/8] mm,memory_hotplug: Allocate memmap from the added memory range Oscar Salvador
2021-04-20 10:56   ` Michal Hocko
2021-04-21  8:15     ` Oscar Salvador
2021-04-21  8:39       ` Michal Hocko [this message]
2021-04-21  8:44         ` David Hildenbrand
2021-04-21  8:49           ` Michal Hocko
2021-04-21  8:52             ` David Hildenbrand
2021-04-21  8:46         ` Oscar Salvador
2021-04-16 11:24 ` [PATCH v9 5/8] acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported Oscar Salvador
2021-04-16 11:24 ` [PATCH v9 6/8] mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory Oscar Salvador
2021-04-16 11:24 ` [PATCH v9 7/8] x86/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE Oscar Salvador
2021-04-20 10:56   ` Michal Hocko
2021-04-16 11:24 ` [PATCH v9 8/8] arm64/Kconfig: " Oscar Salvador

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=YH/ktDG/9o2OHNGj@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@soleen.com \
    --cc=vbabka@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).