All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pingfan Liu <kernelfans@gmail.com>
To: Chao Fan <fanc.fnst@cn.fujitsu.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, Yinghai Lu <yinghai@kernel.org>,
	Tejun Heo <tj@kernel.org>, Baoquan He <bhe@redhat.com>,
	Juergen Gross <jgross@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
	x86@kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCHv2 1/7] x86/mm: concentrate the code to memblock allocator enabled
Date: Fri, 11 Jan 2019 18:06:55 +0800	[thread overview]
Message-ID: <CAFgQCTvhcNK_-b-eVFZY8Ua2C+GbOVM+h4kB1us2vNvvyNPCYg@mail.gmail.com> (raw)
In-Reply-To: <20190111061221.GB13263@localhost.localdomain>

On Fri, Jan 11, 2019 at 2:13 PM Chao Fan <fanc.fnst@cn.fujitsu.com> wrote:
>
> On Fri, Jan 11, 2019 at 01:12:51PM +0800, Pingfan Liu wrote:
> >This patch identifies the point where memblock alloc start. It has no
> >functional.
> [...]
> >+#ifdef CONFIG_MEMORY_HOTPLUG
> >+      /*
> >+       * Memory used by the kernel cannot be hot-removed because Linux
> >+       * cannot migrate the kernel pages. When memory hotplug is
> >+       * enabled, we should prevent memblock from allocating memory
> >+       * for the kernel.
> >+       *
> >+       * ACPI SRAT records all hotpluggable memory ranges. But before
> >+       * SRAT is parsed, we don't know about it.
> >+       *
> >+       * The kernel image is loaded into memory at very early time. We
> >+       * cannot prevent this anyway. So on NUMA system, we set any
> >+       * node the kernel resides in as un-hotpluggable.
> >+       *
> >+       * Since on modern servers, one node could have double-digit
> >+       * gigabytes memory, we can assume the memory around the kernel
> >+       * image is also un-hotpluggable. So before SRAT is parsed, just
> >+       * allocate memory near the kernel image to try the best to keep
> >+       * the kernel away from hotpluggable memory.
> >+       */
> >+      if (movable_node_is_enabled())
> >+              memblock_set_bottom_up(true);
>
> Hi Pingfan,
>
> In my understanding, 'movable_node' is based on the that memory near
> kernel is considered as in the same node as kernel in high possibility.
>
> If SRAT has been parsed early, do we still need the kernel parameter
> 'movable_node'? Since you have got the memory information about hot-remove,
> so I wonder if it's OK to drop 'movable_node', and if memory-hotremove is
> enabled, change memblock allocation according to SRAT.
>
x86_32 still need this logic. Maybe it can be doable later.

Thanks,
Pingfan
> If there is something wrong in my understanding, please let me know.
>
> Thanks,
> Chao Fan
>
> >+#endif
> >       init_mem_mapping();
> >+      memblock_set_current_limit(get_max_mapped());
> >
> >       idt_setup_early_pf();
> >
> >@@ -1145,8 +1145,6 @@ void __init setup_arch(char **cmdline_p)
> >        */
> >       mmu_cr4_features = __read_cr4() & ~X86_CR4_PCIDE;
> >
> >-      memblock_set_current_limit(get_max_mapped());
> >-
> >       /*
> >        * NOTE: On x86-32, only from this point on, fixmaps are ready for use.
> >        */
> >--
> >2.7.4
> >
> >
> >
>
>

  reply	other threads:[~2019-01-11 10:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11  5:12 [PATCHv2 0/7] x86_64/mm: remove bottom-up allocation style by pushing forward the parsing of mem hotplug info Pingfan Liu
2019-01-11  5:12 ` [PATCHv2 1/7] x86/mm: concentrate the code to memblock allocator enabled Pingfan Liu
2019-01-11  6:12   ` Chao Fan
2019-01-11  6:12     ` Chao Fan
2019-01-11 10:06     ` Pingfan Liu [this message]
2019-01-11 10:06       ` Pingfan Liu
2019-01-14 23:07   ` Dave Hansen
2019-01-15  7:06     ` Pingfan Liu
2019-01-15  7:06       ` Pingfan Liu
2019-01-11  5:12 ` [PATCHv2 2/7] acpi: change the topo of acpi_table_upgrade() Pingfan Liu
2019-01-11  5:30   ` Chao Fan
2019-01-11  5:30     ` Chao Fan
2019-01-11 10:08     ` Pingfan Liu
2019-01-11 10:08       ` Pingfan Liu
2019-01-14 23:12   ` Dave Hansen
2019-01-15  7:28     ` Pingfan Liu
2019-01-15  7:28       ` Pingfan Liu
2019-01-11  5:12 ` [PATCHv2 3/7] mm/memblock: introduce allocation boundary for tracing purpose Pingfan Liu
2019-01-14  7:51   ` Mike Rapoport
2019-01-14  8:33     ` Pingfan Liu
2019-01-14  8:33       ` Pingfan Liu
2019-01-14  8:50       ` Mike Rapoport
2019-01-14  9:13         ` Pingfan Liu
2019-01-14  9:13           ` Pingfan Liu
2019-01-11  5:12 ` [PATCHv2 4/7] x86/setup: parse acpi to get hotplug info before init_mem_mapping() Pingfan Liu
2019-01-11  5:12 ` [PATCHv2 5/7] x86/mm: set allowed range for memblock allocator Pingfan Liu
2019-01-11  5:12 ` [PATCHv2 6/7] x86/mm: remove bottom-up allocation style for x86_64 Pingfan Liu
2019-01-14 23:27   ` Dave Hansen
2019-01-15  7:38     ` Pingfan Liu
2019-01-15  7:38       ` Pingfan Liu
2019-01-11  5:12 ` [PATCHv2 7/7] x86/mm: isolate the bottom-up style to init_32.c Pingfan Liu
2019-01-14 23:02 ` [PATCHv2 0/7] x86_64/mm: remove bottom-up allocation style by pushing forward the parsing of mem hotplug info Dave Hansen
2019-01-15  6:06   ` Pingfan Liu
2019-01-15  6:06     ` Pingfan Liu

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=CAFgQCTvhcNK_-b-eVFZY8Ua2C+GbOVM+h4kB1us2vNvvyNPCYg@mail.gmail.com \
    --to=kernelfans@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fanc.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    --cc=yinghai@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.