All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>,
	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 v7 4/8] mm,memory_hotplug: Allocate memmap from the added memory range
Date: Fri, 16 Apr 2021 10:32:01 +0200	[thread overview]
Message-ID: <de248f48-e45f-7318-a9b6-569bb6b2e736@redhat.com> (raw)
In-Reply-To: <YHk8BCKwpKY0TM6p@localhost.localdomain>

On 16.04.21 09:25, Oscar Salvador wrote:
> On Thu, Apr 15, 2021 at 01:19:59PM +0200, David Hildenbrand wrote:
>>> Implementation wise we will reuse vmem_altmap infrastructure to override
>>> the default allocator used by __populate_section_memmap.
>>> Part of the implementation also relies on memory_block structure gaining
>>> a new field which specifies the number of vmemmap_pages at the beginning.
>>> This patch also introduces the following functions:
>>>
>>>    - vmemmap_init_space: Initializes vmemmap pages by calling move_pfn_range_to_zone(),
>>> 		       calls kasan_add_zero_shadow() or the vmemmap range and marks
>>> 		       online as many sections as vmemmap pages fully span.
>>>    - vmemmap_adjust_pages: Accounts/substract vmemmap_pages to node and zone
>>> 			 present_pages
>>>    - vmemmap_deinit_space: Undoes what vmemmap_init_space does.
>>>
>>
>> This is a bit asynchronous; and the function names are not really expressing what is being done :) I'll try to come up with better names below.
> 
> Yeah, was not happy either with the names but at that time I could not
> come up with anything better.
> 
>> It is worth mentioning that the real "mess" is that we want offline_pages() to properly handle zone->present_pages going to 0. Therefore, we want to manually mess with the present page count.
> 
> This should be explained by this:
> 
> "On offline, memory_block_offline() calls vmemmap_adjust_pages() prior to calling
> offline_pages(), because offline_pages() performs the tearing-down of kthreads
> and the rebuilding of the zonelists if the node/zone become empty."
> 
> Is not that clear?

Ehm, it is; for some reason my eyes ignored it -- sorry.

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-04-16  8:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 12:17 [PATCH v7 0/8] Allocate memmap from hotadded memory (per device) Oscar Salvador
2021-04-08 12:17 ` [PATCH v7 1/8] drivers/base/memory: Introduce memory_block_{online,offline} Oscar Salvador
2021-04-08 12:17 ` [PATCH v7 2/8] mm,memory_hotplug: Relax fully spanned sections check Oscar Salvador
2021-04-08 12:17 ` [PATCH v7 3/8] mm,memory_hotplug: Factor out adjusting present pages into adjust_present_page_count() Oscar Salvador
2021-04-08 12:18 ` [PATCH v7 4/8] mm,memory_hotplug: Allocate memmap from the added memory range Oscar Salvador
2021-04-15 11:19   ` David Hildenbrand
2021-04-16  7:25     ` Oscar Salvador
2021-04-16  8:32       ` David Hildenbrand [this message]
2021-04-08 12:18 ` [PATCH v7 5/8] acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported Oscar Salvador
2021-04-08 12:18 ` [PATCH v7 6/8] mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory Oscar Salvador
2021-04-08 12:18 ` [PATCH v7 7/8] x86/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE Oscar Salvador
2021-04-08 13:36   ` Christoph Hellwig
2021-04-08 18:19     ` David Hildenbrand
2021-04-08 12:18 ` [PATCH v7 8/8] arm64/Kconfig: " Oscar Salvador
2021-04-15 10:38 ` [PATCH v7 0/8] Allocate memmap from hotadded memory (per device) 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=de248f48-e45f-7318-a9b6-569bb6b2e736@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.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 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.