Re: [PATCH 1/3] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

On 11/10/16 at 05:27pm, Hari Bathini wrote: > Traditionally, kdump is used to save vmcore in case of a crash. Some > architectures like powerpc can save vmcore using architecture specific > support instead of kexec/kdump mechanism. Such architecture specific > support also needs to reserve memory,

Re: [RFC] kexec_file: Add support for purgatory built as PIE

On 11/02/16 at 04:00am, Thiago Jung Bauermann wrote: > Hello, > > The kexec_file code currently builds the purgatory as a partially linked > object > (using ld -r). Is there a particular reason to use that instead of a position > independent executable (PIE)? It's taken as "-r", relocatable

Re: [PATCH v7 3/4] lib/cmdline.c Remove quotes symmetrically.

On 08/17/17 at 10:14pm, Michal Suchanek wrote: > Remove quotes from argument value only if there is qoute on both sides. > > Signed-off-by: Michal Suchanek Sounds reasonable. Just for curiosity, do we have chance to pass in option with a single '"'? > --- >

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 06/12/18 at 11:28am, Baoquan He wrote: > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > so that it's shared. Later its code also need be updated using list_head > to replace singly

[PATCH v5 4/4] kexec_file: Load kernel at top of system RAM if required

. Signed-off-by: Baoquan He Cc: Eric Biederman Cc: Vivek Goyal Cc: Dave Young Cc: Andrew Morton Cc: Yinghai Lu Cc: ke...@lists.infradead.org --- kernel/kexec_file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 75d8e7cf040e..7a66d9d5a534

[PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c so that it's shared. Later its code also need be updated using list_head to replace singly linked list. Signed-off-by: Baoquan He Cc: Michal Simek Cc

[PATCH v5 2/4] resource: Use list_head to link sibling resource

of member variables of struct resource, sibling and child, are changed from 'struct resource *' to 'struct list_head'. This brings two pointers of size increase. Suggested-by: Andrew Morton Signed-off-by: Baoquan He Cc: Patrik Jakobsson Cc: David Airlie Cc: "K. Y. Srinivasan" Cc: Hai

[PATCH v5 0/4] resource: Use list_head to link sibling resource

is suggested by Andrew. Rewrite walk_system_ram_res_rev() after list_head is taken to link resouce siblings. Baoquan He (4): resource: Move reparent_resources() to kernel/resource.c and make it public resource: Use list_head to link sibling resource resource: add walk_system

[PATCH v5 3/4] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He Cc: Andrew Morton Cc: Thomas Gleixner Cc: Brijesh Singh Cc: "Jérôme Glisse" Cc: Borislav Petkov Cc: Tom Lendacky Cc: Wei Yang --- include/linux/ioport.h | 3 +++ kernel/resource.c | 40 2 files ch

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 06/12/18 at 11:29am, Andy Shevchenko wrote: > On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote: > > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > > so that it's shared

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 06/12/18 at 11:29am, Andy Shevchenko wrote: > On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote: > > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > > so that it's shared

Re: [PATCH v5 2/4] resource: Use list_head to link sibling resource

On 06/12/18 at 05:10pm, Julia Lawall wrote: > This looks wrong. After a list iterator, the index variable points to a > dummy structure. > > julia > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180612-1

[PATCH v6 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c so that it's shared. Signed-off-by: Baoquan He --- arch/microblaze/pci/pci-common.c | 37 - arch/powerpc/kernel/pci

[PATCH v6 4/4] kexec_file: Load kernel at top of system RAM if required

. Signed-off-by: Baoquan He Cc: Eric Biederman Cc: Vivek Goyal Cc: Dave Young Cc: Andrew Morton Cc: Yinghai Lu Cc: ke...@lists.infradead.org --- kernel/kexec_file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index c6a3b6851372..75226c1d08ce

[PATCH v6 3/4] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He Cc: Andrew Morton Cc: Thomas Gleixner Cc: Brijesh Singh Cc: "Jérôme Glisse" Cc: Borislav Petkov Cc: Tom Lendacky Cc: Wei Yang --- include/linux/ioport.h | 3 +++ kernel/resource.c | 40 2 files ch

[PATCH v6 0/4] resource: Use list_head to link sibling resource

link resouce siblings. Baoquan He (4): resource: Move reparent_resources() to kernel/resource.c and make it public resource: Use list_head to link sibling resource resource: add walk_system_ram_res_rev() kexec_file: Load kernel at top of system RAM if required arch/arm/plat-sam

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 07/03/18 at 11:57pm, Andy Shevchenko wrote: > On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote: > > On 06/12/18 at 05:24pm, Andy Shevchenko wrote: > >> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko > >> wrote: > > >> > I briefly looked at the cod

[PATCH v6 2/4] resource: Use list_head to link sibling resource

of member variables of struct resource, sibling and child, are changed from 'struct resource *' to 'struct list_head'. This brings two pointers of size increase. Suggested-by: Andrew Morton Signed-off-by: Baoquan He Cc: Patrik Jakobsson Cc: David Airlie Cc: "K. Y. Srinivasan" Cc: Hai

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

Hi Andy, On 06/12/18 at 05:24pm, Andy Shevchenko wrote: > On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko > wrote: > >> Hmm, I just copied it from arch/powerpc/kernel/pci-common.c. The > >> function interface expects an integer returned value, not sure what a > >> real error codes look like,

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

On 07/26/18 at 02:59pm, Michal Hocko wrote: > On Wed 25-07-18 14:48:13, Baoquan He wrote: > > On 07/23/18 at 04:34pm, Michal Hocko wrote: > > > On Thu 19-07-18 23:17:53, Baoquan He wrote: > > > > Kexec has been a formal feature in our distro, and customers owning &g

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

On 07/26/18 at 03:14pm, Michal Hocko wrote: > On Thu 26-07-18 15:12:42, Michal Hocko wrote: > > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > > On 07/26/18 at 02:59pm, Michal Hocko wrote: > > > > On Wed 25-07-18 14:48:13, Baoquan He wrote: > > > > &g

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

On 07/26/18 at 04:01pm, Michal Hocko wrote: > On Thu 26-07-18 21:37:05, Baoquan He wrote: > > On 07/26/18 at 03:14pm, Michal Hocko wrote: > > > On Thu 26-07-18 15:12:42, Michal Hocko wrote: > > > > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > > > &g

[PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

. Signed-off-by: Baoquan He Cc: Eric Biederman Cc: Vivek Goyal Cc: Dave Young Cc: Andrew Morton Cc: Yinghai Lu Cc: ke...@lists.infradead.org --- kernel/kexec_file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index c6a3b6851372..75226c1d08ce

[PATCH v7 0/4] resource: Use list_head to link sibling resource

d to link resource siblings. This is suggested by Andrew. Rewrite walk_system_ram_res_rev() after list_head is taken to link resouce siblings. Baoquan He (4): resource: Move reparent_resources() to kernel/resource.c and make it public resource: Use list_head to link sibling resour

[PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c so that it's shared. Reviewed-by: Andy Shevchenko Signed-off-by: Baoquan He Cc: Michal Simek Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

[PATCH v7 2/4] resource: Use list_head to link sibling resource

of member variables of struct resource, sibling and child, are changed from 'struct resource *' to 'struct list_head'. This brings two pointers of size increase. Suggested-by: Andrew Morton Signed-off-by: Baoquan He Cc: Patrik Jakobsson Cc: David Airlie Cc: "K. Y. Srinivasan" Cc: Hai

[PATCH v7 3/4] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He Cc: Andrew Morton Cc: Thomas Gleixner Cc: Brijesh Singh Cc: "Jérôme Glisse" Cc: Borislav Petkov Cc: Tom Lendacky Cc: Wei Yang --- include/linux/ioport.h | 3 +++ kernel/resource.c | 40 2 files ch

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

Hi Andrew, On 07/19/18 at 12:44pm, Andrew Morton wrote: > On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote: > > > As far as I can tell, the above is the whole reason for the patchset, > > > yes? To avoid confusing users. > > > > > > In fact, it's n

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

Hi Andrew, On 07/18/18 at 03:33pm, Andrew Morton wrote: > On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote: > > > For kexec_file loading, if kexec_buf.top_down is 'true', the memory which > > is used to load kernel/initrd/purgatory is supposed to be allocated fr

Re: [PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 07/18/18 at 07:37pm, Andy Shevchenko wrote: > On Wed, Jul 18, 2018 at 7:36 PM, Andy Shevchenko > wrote: > > On Wed, Jul 18, 2018 at 5:49 AM, Baoquan He wrote: > >> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > >> and arch/powerp

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

On 07/23/18 at 04:34pm, Michal Hocko wrote: > On Thu 19-07-18 23:17:53, Baoquan He wrote: > > Kexec has been a formal feature in our distro, and customers owning > > those kind of very large machine can make use of this feature to speed > > up the reboot process. On uefi ma

Re: [PATCH v6 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 07/04/18 at 07:46pm, Andy Shevchenko wrote: > On Wed, Jul 4, 2018 at 7:10 AM, Baoquan He wrote: > > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > > so that it's sha

Re: [PATCH v6 2/4] resource: Use list_head to link sibling resource

On 07/08/18 at 08:48pm, Andy Shevchenko wrote: > On Sun, Jul 8, 2018 at 5:59 AM, Baoquan He wrote: > > On 07/05/18 at 01:00am, kbuild test robot wrote: > > > However, I didn't find below branch. And tried to open it in web > > broswer, also failed. > > W

Re: [kbuild-all] [PATCH v6 2/4] resource: Use list_head to link sibling resource

On 07/10/18 at 08:59am, Ye Xiaolong wrote: > Hi, > > On 07/08, Baoquan He wrote: > >Hi, > > > >On 07/05/18 at 01:00am, kbuild test robot wrote: > >> Hi Baoquan, > >> > >> I love your patch! Yet something to improve: > >> > >

Re: Boot failures with "mm/sparse: Remove CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER" on powerpc (was Re: mmotm 2018-07-10-16-50 uploaded)

Hi Michael, On 07/11/18 at 10:49pm, Michael Ellerman wrote: > a...@linux-foundation.org writes: > > The mm-of-the-moment snapshot 2018-07-10-16-50 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > ... > > > * mm-sparse-add-a-static-variable-nr_present_sections.patch > > *

Re: [PATCH v6 2/4] resource: Use list_head to link sibling resource

please drop us a note to > help improve the system] Thanks for telling. I cloned 0day-ci/linut to my local pc. https://github.com/0day-ci/linux.git However, I didn't find below branch. And tried to open it in web broswer, also failed. > url: > https://github.com/0day-ci/linux/commits/Bao

Re: Is it worth to fix the crashkernel reserved memory blocks the hotplug issue?

On 12/10/18 at 12:08pm, Pingfan Liu wrote: > Hi, > I found in powerpc code, it is doable to reserve memory region in > movable zone, such as crashkernel does. But in x86 code, it checks the > hotpluggable attribute of memory, hence if manually specifying a > region in hotpluggable region, it will

Re: [PATCH v3 04/27] ocxl: Remove unnecessary externs

On 02/21/20 at 02:26pm, Alastair D'Silva wrote: > From: Alastair D'Silva > > Function declarations don't need externs, remove the existing ones > so they are consistent with newer code > > Signed-off-by: Alastair D'Silva > --- > arch/powerpc/include/asm/pnv-ocxl.h | 32

Re: [PATCH v3 04/27] ocxl: Remove unnecessary externs

On 02/26/20 at 03:20pm, Greg Kurz wrote: > On Wed, 26 Feb 2020 22:15:23 +0800 > 'Baoquan He' wrote: > > > On 02/26/20 at 10:01am, Greg Kurz wrote: > > > On Wed, 26 Feb 2020 19:26:34 +1100 > > > "Alastair D'Silva" wrote: > > > > > &

Re: [PATCH v3 04/27] ocxl: Remove unnecessary externs

On 02/26/20 at 10:01am, Greg Kurz wrote: > On Wed, 26 Feb 2020 19:26:34 +1100 > "Alastair D'Silva" wrote: > > > > -Original Message- > > > From: Baoquan He > > > Sent: Wednesday, 26 February 2020 7:15 PM > > > To: Alastair D'Si

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

On 10/06/19 at 10:56am, David Hildenbrand wrote: > If we have holes, the holes will automatically get detected and removed > once we remove the next bigger/smaller section. The extra checks can > go. > > Cc: Andrew Morton > Cc: Oscar Salvador > Cc: Michal Hocko > Cc: David Hildenbrand > Cc:

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

On 02/06/20 at 07:26am, Wei Yang wrote: > On Thu, Feb 06, 2020 at 07:08:26AM +0800, Baoquan He wrote: > >On 02/06/20 at 06:56am, Wei Yang wrote: > >> On Wed, Feb 05, 2020 at 10:48:11PM +0800, Baoquan He wrote: > >> >Hi Wei Yang, > >> > > >> >

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

On 02/06/20 at 06:56am, Wei Yang wrote: > On Wed, Feb 05, 2020 at 10:48:11PM +0800, Baoquan He wrote: > >Hi Wei Yang, > > > >On 02/05/20 at 05:59pm, Wei Yang wrote: > >> >diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > >> >index f29

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

On 02/04/20 at 03:42pm, David Hildenbrand wrote: > On 04.02.20 15:25, Baoquan He wrote: > > On 10/06/19 at 10:56am, David Hildenbrand wrote: > >> If we have holes, the holes will automatically get detected and removed > >> once we remove the next bigger/smaller se

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

On 02/05/20 at 03:16pm, David Hildenbrand wrote: > Anyhow, that patch is already upstream and I don't consider this high > priority. Thanks :) > >>> > >>> Yeah, noticed you told Wei the status in another patch thread, I am fine > >>> with it, just leave it to you to decide. Thanks. > >>

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

On 02/05/20 at 02:20pm, David Hildenbrand wrote: > On 05.02.20 13:43, Baoquan He wrote: > > On 02/04/20 at 03:42pm, David Hildenbrand wrote: > >> On 04.02.20 15:25, Baoquan He wrote: > >>> On 10/06/19 at 10:56am, David Hildenbrand wrote: > >>>> If we

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

Hi Wei Yang, On 02/05/20 at 05:59pm, Wei Yang wrote: > >diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > >index f294918f7211..8dafa1ba8d9f 100644 > >--- a/mm/memory_hotplug.c > >+++ b/mm/memory_hotplug.c > >@@ -393,6 +393,9 @@ static void shrink_zone_span(struct zone *zone, unsigned >

Re: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

On 02/05/20 at 02:38pm, David Hildenbrand wrote: > On 05.02.20 14:34, Baoquan He wrote: > > On 02/05/20 at 02:20pm, David Hildenbrand wrote: > >> On 05.02.20 13:43, Baoquan He wrote: > >>> On 02/04/20 at 03:42pm, David Hildenbrand wrote: > >>>> On 04.02

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 04/09/20 at 07:27pm, Mike Rapoport wrote: > On Tue, Mar 31, 2020 at 04:21:38PM +0200, Michal Hocko wrote: > > On Tue 31-03-20 22:03:32, Baoquan He wrote: > > > Hi Michal, > > > > > > On 03/31/20 at 10:55am, Michal Hocko wrote: > > > &g

Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)

On 04/09/20 at 05:33pm, Michal Hocko wrote: > On Thu 09-04-20 22:41:19, Baoquan He wrote: > > On 04/02/20 at 10:01am, Michal Hocko wrote: > > > On Wed 01-04-20 10:51:55, Mike Rapoport wrote: > > > > Hi, > > > > > > > > On W

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/14/20 at 04:49pm, David Hildenbrand wrote: > > The root cause is kexec-ed kernel is targeted at hotpluggable memory > > region. Just avoiding the movable area can fix it. In kexec_file_load(), > > just checking or picking those unmovable region to put kernel/initrd in > >

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/16/20 at 04:09pm, David Hildenbrand wrote: > >>> Sounds doable to me, and not complicated. > >>> > images. It would apply to > > - arm64 and filter out all hotadded memory (IIRC, only boot memory can > be used). > >>> > >>> Do you mean hot added memory after boot can't

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/16/20 at 03:31pm, David Hildenbrand wrote: > > Not sure if I get the notifier idea clearly. If you mean > > > > 1) Add a common function to pick memory in unmovable zone; > > Not strictly required IMHO. But, minor detail. > > > 2) Let DLPAR, balloon register with notifier; > > Yeah, or

Re: [PATCH v1 1/2] powerpc/pseries/hotplug-memory: stop checking is_mem_section_removable()

el Ellerman > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michal Hocko > Cc: Andrew Morton > Cc: Oscar Salvador > Cc: Baoquan He > Cc: Wei Yang > Signed-off-by: David Hildenbrand > --- > .../platforms/pseries/hotplug-memory.c| 26 +++--

Re: [PATCH v1 2/2] mm/memory_hotplug: remove is_mem_section_removable()

Cc: Oscar Salvador > Cc: Baoquan He > Cc: Wei Yang > Signed-off-by: David Hildenbrand Assuming no issue to patch 1, this one looks good. Reviewed-by: Baoquan He > --- > include/linux/memory_hotplug.h | 7 > mm/memory_hotplug.c| 75 -

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/14/20 at 10:00am, David Hildenbrand wrote: > On 14.04.20 08:40, Baoquan He wrote: > > On 04/13/20 at 08:15am, Eric W. Biederman wrote: > >> Baoquan He writes: > >> > >>> On 04/12/20 at 02:52pm, Eric W. Biederman wrote: > >>>> > >

Re: [PATCH 01/21] mm: memblock: replace dereferences of memblock_region.nid with API calls

continue; > > - nid = r->nid; > + nid = memblock_get_region_node(r); > > usable_startpfn = PFN_DOWN(r->base); > zone_movable_pfn[nid] = zone_movable_pfn[nid] ? > @@ -7229,7 +7229,7 @@ static void __init > find_zone_movable_pfns_for_nodes(void) > if (memblock_is_mirror(r)) > continue; > > - nid = r->nid; > + nid = memblock_get_region_node(r); > > usable_startpfn = memblock_region_memory_base_pfn(r); Looks good to me. Reviewed-by: Baoquan He

Re: [PATCH 02/21] mm: make early_pfn_to_nid() and related defintions close to each other

On 04/12/20 at 10:48pm, Mike Rapoport wrote: > From: Mike Rapoport > > The early_pfn_to_nid() and it's helper __early_pfn_to_nid() are spread > around include/linux/mm.h, include/linux/mmzone.h and mm/page_alloc.c. > > Drop unused stub for __early_pfn_to_nid() and move its actual generic >

Re: [PATCH 02/21] mm: make early_pfn_to_nid() and related defintions close to each other

O_NID) || \ defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP) This is the upper layer of ifdeffery scope. > > static struct mminit_pfnnid_cache early_pfnnid_cache __meminitdata; > > +#ifndef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID Moving __early_pfn_to_nid() here makes the upper layer of ifdeferry s

Re: [PATCH 03/21] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option

On 04/12/20 at 10:48pm, Mike Rapoport wrote: > From: Mike Rapoport > > The CONFIG_HAVE_MEMBLOCK_NODE_MAP is used to differentiate initialization > of nodes and zones structures between the systems that have region to node > mapping in memblock and those that don't. > > Currently all the NUMA

Re: [PATCH 02/21] mm: make early_pfn_to_nid() and related defintions close to each other

On 04/21/20 at 11:49am, Mike Rapoport wrote: > On Tue, Apr 21, 2020 at 10:24:35AM +0800, Baoquan He wrote: > > On 04/12/20 at 10:48pm, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > The early_pfn_to_nid() and it's helper __early_pfn_to_nid() are sp

Re: [PATCH 03/21] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option

On 04/21/20 at 12:09pm, Mike Rapoport wrote: > > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > > > index fc0aad0bc1f5..e67dc501576a 100644 > > > --- a/mm/memory_hotplug.c > > > +++ b/mm/memory_hotplug.c > > > @@ -1372,11 +1372,7 @@ check_pages_isolated_cb(unsigned long start_pfn, > >

Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)

On 04/02/20 at 10:01am, Michal Hocko wrote: > On Wed 01-04-20 10:51:55, Mike Rapoport wrote: > > Hi, > > > > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote: > [...] > > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and > > >

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 04/02/20 at 09:46pm, Hoan Tran wrote: > Hi All, > > On 3/31/20 7:31 AM, Baoquan He wrote: > > On 03/31/20 at 04:21pm, Michal Hocko wrote: > > > On Tue 31-03-20 22:03:32, Baoquan He wrote: > > > > Hi Michal, > > > > > > > > On 03/31/

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 03/28/20 at 11:31am, Hoan Tran wrote: > In NUMA layout which nodes have memory ranges that span across other nodes, > the mm driver can detect the memory node id incorrectly. > > For example, with layout below > Node 0 address: > Node 1 address: Sorry,

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 03/31/20 at 04:21pm, Michal Hocko wrote: > On Tue 31-03-20 22:03:32, Baoquan He wrote: > > Hi Michal, > > > > On 03/31/20 at 10:55am, Michal Hocko wrote: > > > On Tue 31-03-20 11:14:23, Mike Rapoport wrote: > > > > Maybe I mis-read the c

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

Hi Michal, On 03/31/20 at 10:55am, Michal Hocko wrote: > On Tue 31-03-20 11:14:23, Mike Rapoport wrote: > > Maybe I mis-read the code, but I don't see how this could happen. In the > > HAVE_MEMBLOCK_NODE_MAP=y case, free_area_init_node() calls > > calculate_node_totalpages() that ensures that

Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)

On 04/01/20 at 12:56am, Mike Rapoport wrote: > On Mon, Mar 30, 2020 at 11:58:43AM +0200, Michal Hocko wrote: > > > > What would it take to make ia64 use HAVE_MEMBLOCK_NODE_MAP? I would > > really love to see that thing go away. It is causing problems when > > people try to use memblock api. > >

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 03/30/20 at 09:42am, Michal Hocko wrote: > On Sat 28-03-20 11:31:17, Hoan Tran wrote: > > In NUMA layout which nodes have memory ranges that span across other nodes, > > the mm driver can detect the memory node id incorrectly. > > > > For example, with layout below > > Node 0 address:

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 03/30/20 at 04:16pm, Baoquan He wrote: > On 03/30/20 at 09:42am, Michal Hocko wrote: > > On Sat 28-03-20 11:31:17, Hoan Tran wrote: > > > In NUMA layout which nodes have memory ranges that span across other > > > nodes, > > > the mm driver can d

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 03/30/20 at 01:26pm, Mike Rapoport wrote: > On Mon, Mar 30, 2020 at 11:58:43AM +0200, Michal Hocko wrote: > > On Mon 30-03-20 12:21:27, Mike Rapoport wrote: > > > On Mon, Mar 30, 2020 at 09:42:46AM +0200, Michal Hocko wrote: > > > > On Sat 28-03-20 11:31:17, Hoan Tran wrote: > > > > > In NUMA

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 03/30/20 at 09:44am, Michal Hocko wrote: > On Sun 29-03-20 08:19:24, Baoquan He wrote: > > On 03/28/20 at 11:31am, Hoan Tran wrote: > > > In NUMA layout which nodes have memory ranges that span across other > > > nodes, > > > the mm driver can d

Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA

On 03/30/20 at 09:42am, Michal Hocko wrote: > On Sat 28-03-20 11:31:17, Hoan Tran wrote: > > In NUMA layout which nodes have memory ranges that span across other nodes, > > the mm driver can detect the memory node id incorrectly. > > > > For example, with layout below > > Node 0 address:

Re: [PATCH] mm/sparse: Fix kernel crash with pfn_section_valid check

On 03/25/20 at 01:42pm, Aneesh Kumar K.V wrote: > On 3/25/20 1:07 PM, Baoquan He wrote: > > On 03/25/20 at 03:06pm, Baoquan He wrote: > > > On 03/25/20 at 08:49am, Aneesh Kumar K.V wrote: > > > > > > mm/sparse.c | 2 ++ > > > > 1 file changed,

Re: [PATCH] mm/sparse: Fix kernel crash with pfn_section_valid check

ection_valid(ms, pfn); > } > > where > > static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn) > { > int idx = subsection_map_index(pfn); > > return test_bit(idx, ms->usage->subsection_map); > } > > Avoid this by cleari

Re: [PATCH] mm/sparse: Fix kernel crash with pfn_section_valid check

On 03/25/20 at 03:06pm, Baoquan He wrote: > On 03/25/20 at 08:49am, Aneesh Kumar K.V wrote: > > mm/sparse.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/sparse.c b/mm/sparse.c > > index aadb7298dcef..3012d1f3771a 100644 > >

Re: [PATCH v2] mm/sparse: Fix kernel crash with pfn_section_valid check

r vmmemap mapping > (16MB), > a specific vmemmap mapping can cover multiple sections. Hence before a vmemmap > mapping page can be freed, the kernel needs to make sure there are no valid > sections > within that mapping. Clearing the section valid bit before > depopulate_section_memap ena

Re: [PATCH 17/21] mm: free_area_init: allow defining max_zone_pfn in descending order

On 04/23/20 at 08:55am, Mike Rapoport wrote: > On Thu, Apr 23, 2020 at 10:57:20AM +0800, Baoquan He wrote: > > On 04/23/20 at 10:53am, Baoquan He wrote: > > > On 04/12/20 at 10:48pm, Mike Rapoport wrote: > > > > From: Mike Rapoport > > > >

Re: [PATCH 05/21] mm: use free_area_init() instead of free_area_init_nodes()

all pg_data_t and zone data > * @max_zone_pfn: an array of max PFNs for each zone > * > * This will call free_area_init_node() for each active node in the system. It's __free_area_init_node() here being called, while it dosn't matter much because it's updated in later patch. > @@ -7440,7 +7440,7 @@ static void check_for_memory(pg_data_t *pgdat, int nid) > * starts where the previous one ended. For example, ZONE_DMA32 starts > * at arch_max_dma_pfn. > */ > -void __init free_area_init_nodes(unsigned long *max_zone_pfn) > +void __init free_area_init(unsigned long *max_zone_pfn) > { > unsigned long start_pfn, end_pfn; > int i, nid; > @@ -7700,12 +7700,6 @@ void __init set_dma_reserve(unsigned long > new_dma_reserve) > dma_reserve = new_dma_reserve; > } > > -void __init free_area_init(unsigned long *max_zone_pfn) > -{ > - init_unavailable_mem(); > - free_area_init_nodes(max_zone_pfn); > -} > - > static int page_alloc_cpu_dead(unsigned int cpu) > { Reviewed-by: Baoquan He > > -- > 2.25.1 >

Re: [PATCH 18/21] mm: rename free_area_init_node() to free_area_init_memoryless_node()

On 04/12/20 at 10:48pm, Mike Rapoport wrote: > From: Mike Rapoport > > The free_area_init_node() is only used by x86 to initialize a memory-less > nodes. > Make its name reflect this and drop all the function parameters except node > ID as they are anyway zero. > > Signed-off-by: Mike Rapoport

Re: [PATCH 17/21] mm: free_area_init: allow defining max_zone_pfn in descending order

On 04/23/20 at 10:53am, Baoquan He wrote: > On 04/12/20 at 10:48pm, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the > > ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it

Re: [PATCH 04/21] mm: free_area_init: use maximal zone PFNs rather than zone sizes

linux/mm.h > +++ b/include/linux/mm.h > @@ -2272,7 +2272,7 @@ static inline spinlock_t *pud_lock(struct mm_struct > *mm, pud_t *pud) > } > > extern void __init pagecache_init(void); > -extern void free_area_init(unsigned long * zones_size); > +extern void free_area_init(unsigned long * max_zone_pfn); > extern void __init free_area_init_node(int nid, unsigned long * zones_size, > unsigned long zone_start_pfn, unsigned long *zholes_size); > extern void free_initmem(void); > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 4530e9cfd9f7..530701b38bc7 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -7700,11 +7700,10 @@ void __init set_dma_reserve(unsigned long > new_dma_reserve) > dma_reserve = new_dma_reserve; > } > > -void __init free_area_init(unsigned long *zones_size) > +void __init free_area_init(unsigned long *max_zone_pfn) > { > init_unavailable_mem(); > - free_area_init_node(0, zones_size, > - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL); > + free_area_init_nodes(max_zone_pfn); Reviewed-by: Baoquan He > } > > static int page_alloc_cpu_dead(unsigned int cpu) > -- > 2.25.1 >

Re: [PATCH 16/21] mm: remove early_pfn_in_nid() and CONFIG_NODES_SPAN_OTHER_NODES

p; nid != node) > - return false; > - return true; > -} > - > -#else > -static inline bool __meminit early_pfn_in_nid(unsigned long pfn, int node) > -{ > - return true; > -} > -#endif And macro early_pfn_valid() is not needed either, we may need remove it too. Otherwise, removing NODES_SPAN_OTHER_NODES in this patch looks good. Reviewed-by: Baoquan He > - > - > void __init memblock_free_pages(struct page *page, unsigned long pfn, > unsigned int order) > { > -- > 2.25.1 >

Re: [PATCH 17/21] mm: free_area_init: allow defining max_zone_pfn in descending order

On 04/12/20 at 10:48pm, Mike Rapoport wrote: > From: Mike Rapoport > > Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the > ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is > sorted in descending order allows using free_area_init() on such >

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/22/20 at 12:05pm, David Hildenbrand wrote: > On 22.04.20 11:57, Baoquan He wrote: > > On 04/22/20 at 11:24am, David Hildenbrand wrote: > >> On 22.04.20 11:17, Baoquan He wrote: > >>> On 04/21/20 at 03:29pm, David Hildenbrand wrote: > >>>>&g

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/21/20 at 03:29pm, David Hildenbrand wrote: > >> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't > >> pass the efi, it won't get the SRAT table correctly, if I remember > >> correctly. Yeah, I remeber kvm guest can get memory hotplugged with > >> ACPI only, this

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/22/20 at 11:24am, David Hildenbrand wrote: > On 22.04.20 11:17, Baoquan He wrote: > > On 04/21/20 at 03:29pm, David Hildenbrand wrote: > >>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we > >>>> don't > >>>> pas

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

On 04/14/20 at 11:37am, David Hildenbrand wrote: > On 14.04.20 11:22, Baoquan He wrote: > > On 04/14/20 at 10:00am, David Hildenbrand wrote: > >> On 14.04.20 08:40, Baoquan He wrote: > >>> On 04/13/20 at 08:15am, Eric W. Biederman wrote: > >>>> Baoquan

Re: [PATCH v2 0/8] mm/memory_hotplug: allow to specify a default online_type

On 03/18/20 at 02:54pm, Michal Hocko wrote: > On Wed 18-03-20 21:05:17, Baoquan He wrote: > > On 03/17/20 at 11:49am, David Hildenbrand wrote: > > > Distributions nowadays use udev rules ([1] [2]) to specify if and > > > how to online hotplugged memory. The rul

Re: [PATCH v2 0/8] mm/memory_hotplug: allow to specify a default online_type

On 03/18/20 at 02:58pm, Vitaly Kuznetsov wrote: > Baoquan He writes: > > > On 03/17/20 at 11:49am, David Hildenbrand wrote: > >> Distributions nowadays use udev rules ([1] [2]) to specify if and > >> how to online hotplugged memory. The rules seem to get more comple

Re: [PATCH v2 0/8] mm/memory_hotplug: allow to specify a default online_type

On 03/17/20 at 11:49am, David Hildenbrand wrote: > Distributions nowadays use udev rules ([1] [2]) to specify if and > how to online hotplugged memory. The rules seem to get more complex with > many special cases. Due to the various special cases, > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE cannot be

Re: [PATCH v2 0/8] mm/memory_hotplug: allow to specify a default online_type

On 03/18/20 at 02:50pm, David Hildenbrand wrote: > On 18.03.20 14:05, Baoquan He wrote: > > On 03/17/20 at 11:49am, David Hildenbrand wrote: > >> Distributions nowadays use udev rules ([1] [2]) to specify if and > >> how to online hotplugged memory. The rul

Re: [PATCH v3 3/8] drivers/base/memory: store mapping between MMOP_* and string in an array

rew Morton > Cc: Michal Hocko > Cc: Oscar Salvador > Cc: "Rafael J. Wysocki" > Cc: Baoquan He > Cc: Wei Yang > Signed-off-by: David Hildenbrand > --- > drivers/base/memory.c | 38 +++--- > 1 file changed, 23 insertions(+), 15 d

Re: [PATCH v3 3/8] drivers/base/memory: store mapping between MMOP_* and string in an array

On 03/20/20 at 10:50am, David Hildenbrand wrote: > On 20.03.20 08:36, Baoquan He wrote: > > On 03/19/20 at 02:12pm, David Hildenbrand wrote: > >> Let's use a simple array which we can reuse soon. While at it, move the > >> string->mmop conversion out of the device ho

Re: [PATCH v3 0/8] mm/memory_hotplug: allow to specify a default online_type

: don't check for memhp_auto_online manually" > -- "mm/memory_hotplug: unexport memhp_auto_online" > - "mm/memory_hotplug: convert memhp_auto_online to store an online_type" > -- No longer touches hv/memtrace code Ack the series. Reviewed-by: Baoquan He

Re: [5.6.0-rc7] Kernel crash while running ndctl tests

Hi Sachin, On 03/24/20 at 11:25am, Sachin Sant wrote: > While running ndctl[1] tests against 5.6.0-rc7 following crash is encountered. > > Bisect leads me to commit d41e2f3bd546 > mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case > > Reverting this commit helps and the tests

Re: [5.6.0-rc7] Kernel crash while running ndctl tests

On 03/24/20 at 03:06pm, Sachin Sant wrote: > > > > On 24-Mar-2020, at 2:45 PM, Aneesh Kumar K.V > > wrote: > > > > Sachin Sant writes: > > > >> While running ndctl[1] tests against 5.6.0-rc7 following crash is > >> encountered. > >> > >> Bisect leads me to commit d41e2f3bd546 > >>

Re: [PATCH] mm/hugetlb: Fix build failure with HUGETLB_PAGE but not HUGEBTLBFS

On 03/17/20 at 08:04am, Christophe Leroy wrote: > When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the > following build failure is encoutered: >From the definition of HUGETLB_PAGE, isn't it relying on HUGETLBFS? I could misunderstand the def_bool, please correct me if I am wrong.

Re: [PATCH 10/15] memblock: make memblock_debug and related functionality private

ernel. > > Signed-off-by: Mike Rapoport > --- > arch/s390/kernel/setup.c | 4 ++-- > include/linux/memblock.h | 12 +--- > mm/memblock.c| 13 +++-- > 3 files changed, 14 insertions(+), 15 deletions(-) Nice clean up. Reviewed-by: Baoquan He >

Re: [PATCH 11/15] memblock: reduce number of parameters in for_each_mem_range()

| 1 + > arch/arm64/kernel/machine_kexec_file.c | 6 ++ > arch/s390/kernel/crash_dump.c | 8 > include/linux/memblock.h | 18 ++ > mm/page_alloc.c| 3 +-- > 5 files changed, 22 insertions(+), 14 deletions(-) Revi

  1   2   3   4   >