On 04/16/21 at 09:00am, Oscar Salvador wrote:
...
> +/*
> + * alloc_and_dissolve_huge_page - Allocate a new page and dissolve the old
> one
> + * @h: struct hstate old page belongs to
> + * @old_page: Old page to dissolve
> + * Returns 0 on success, otherwise negated error.
> + */
> +static int
On 04/12/21 at 08:24am, Andy Lutomirski wrote:
> On Mon, Apr 12, 2021 at 2:52 AM Baoquan He wrote:
> >
> > On 04/11/21 at 06:49pm, Andy Lutomirski wrote:
> > >
> > >
> > > > On Apr 11, 2021, at 6:14 PM, Baoquan He wrote:
> > > >
> >
On 04/11/21 at 06:49pm, Andy Lutomirski wrote:
>
>
> > On Apr 11, 2021, at 6:14 PM, Baoquan He wrote:
> >
> > On 04/09/21 at 07:59pm, H. Peter Anvin wrote:
> >> Why don't we do this unconditionally? At the very best we gain half a
> >> megabyte o
On 04/09/21 at 07:59pm, H. Peter Anvin wrote:
> Why don't we do this unconditionally? At the very best we gain half a
> megabyte of memory (except the trampoline, which has to live there, but it is
> only a few kilobytes.)
This is a great suggestion, thanks. I think we can fix it in this way to
On 04/07/21 at 10:03pm, Lianbo Jiang wrote:
> Some sub-1MB memory regions may be reserved by EFI boot services, and the
> memory regions will be released later in the efi_free_boot_services().
>
> Currently, always reserve all sub-1MB memory regions when the crashkernel
> option is specified, but
> Cc: Jessica Yu
> > Cc: Evan Green
> > Cc: Hsin-Yi Wang
> > Cc: Dave Young
> > Cc: Baoquan He
> > Cc: Vivek Goyal
> > Cc:
> > Signed-off-by: Stephen Boyd
> > ---
> > include/linux/crash_core.h | 6 +-
> > kernel/crash_
find all busy IORESOURCE_SYSTEM_RAM resources, making the function
> behave like walk_system_ram_range().
>
> Cc: Andrew Morton
> Cc: Greg Kroah-Hartman
> Cc: Dan Williams
> Cc: Daniel Vetter
> Cc: Andy Shevchenko
> Cc: Mauro Carvalho Chehab
> Cc: Signed-off-by: Davi
On 03/23/21 at 11:13am, Wan Jiabing wrote:
> linux/pgtable.h has been included at line 11 with annotation.
> So we remove the duplicate one at line 8.
>
> Signed-off-by: Wan Jiabing
Thanks for your posting. But this resend is still not good. I have
pasted the suggested log, wondering why you
On 03/13/21 at 02:35am, menglong8.d...@gmail.com wrote:
> From: Zhang Yunkai
>
> 'linux/pgtable.h' included in 'crash_dump.h' is duplicated.
> It is also included in the 8th line.
Tian Tao posted one to address the same issue, his log is better. Please
update with below to repost.
; - if (!sha_regions)
> + if (!sha_regions) {
> + ret = -ENOMEM;
> goto out_free_desc;
A good catch. Even though the chance of failure is very small, it does
cause issue if happened.
Acked-by: Baoqua
an to use this string in your code?
No objection to this even though it's trivial if no real use case.
Acked-by: Baoquan He
>
> Upstream a patch from the SONiC network operating system [1].
>
> [1]: https://github.com/Azure/sonic-linux-kernel/pull/46
>
> Signed-off-by: P
On 03/02/21 at 05:17pm, Mike Rapoport wrote:
> On Tue, Mar 02, 2021 at 09:04:09PM +0800, Baoquan He wrote:
...
> > > +static void __init early_reserve_memory(void)
> > > +{
> > > + /*
> > > + * Reserve the memory occupied by the kernel between _text and
>
early_reserve_initrd();
> +
> + if (efi_enabled(EFI_BOOT))
> + efi_memblock_x86_reserve_range();
> +
> + memblock_x86_reserve_range_setup_data();
This patch looks good to me, thanks for the effort.
While at it, wondering if we can rename the above
Starovoitov
> Cc: Jessica Yu
> Cc: Evan Green
> Cc: Hsin-Yi Wang
> Cc: Dave Young
> Cc: Baoquan He
> Cc: Vivek Goyal
> Cc:
> Signed-off-by: Stephen Boyd
> ---
> kernel/crash_core.c | 46 -
> 1 file changed, 8 inse
On 02/26/21 at 09:38am, Eric W. Biederman wrote:
> chenzhou writes:
>
> > On 2021/2/25 15:25, Baoquan He wrote:
> >> On 02/24/21 at 02:19pm, Catalin Marinas wrote:
> >>> On Sat, Jan 30, 2021 at 03:10:15PM +0800, Chen Zhou wrote:
> >>>> Move
On 02/25/21 at 02:42pm, Catalin Marinas wrote:
> On Thu, Feb 25, 2021 at 03:08:46PM +0800, Baoquan He wrote:
> > On 02/24/21 at 02:35pm, Catalin Marinas wrote:
> > > On Sat, Jan 30, 2021 at 03:10:16PM +0800, Chen Zhou wrote:
> > > > diff --git a/arch/x86/kernel/set
On 02/24/21 at 02:19pm, Catalin Marinas wrote:
> On Sat, Jan 30, 2021 at 03:10:15PM +0800, Chen Zhou wrote:
> > Move CRASH_ALIGN to header asm/kexec.h for later use. Besides, the
> > alignment of crash kernel regions in x86 is 16M(CRASH_ALIGN), but
> > function reserve_crashkernel() also used 1M
On 02/24/21 at 02:35pm, Catalin Marinas wrote:
> On Sat, Jan 30, 2021 at 03:10:16PM +0800, Chen Zhou wrote:
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index da769845597d..27470479e4a3 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@
gned-off-by: Saeed Mirzamohammadi
> Signed-off-by: John Donnelly
> Tested-by: John Donnelly
Looks good, thx.
Acked-by: Baoquan He
By the way, please provide changelog in the future. That can help people
know better what's happened during patch reviewing and evolution.
Thanks
Baoquan
>
On 02/24/21 at 09:54am, Baoquan He wrote:
> On 02/11/21 at 10:08am, Saeed Mirzamohammadi wrote:
> > This adds crashkernel=auto feature to configure reserved memory for
> > vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
> > different kernel distributions and
+
> kernel/crash_core.c | 7 ++
> 4 files changed, 39 insertions(+), 1 deletion(-)
Acked-by: Baoquan He
>
> diff --git a/Documentation/admin-guide/kdump/kdump.rst
> b/Documentation/admin-guide/kdump/kdump.rst
> index 2da65fef2a1c..e55cd
On 02/23/21 at 08:01pm, Kairui Song wrote:
> On Thu, Feb 18, 2021 at 10:03 AM Baoquan He wrote:
> >
> > On 02/11/21 at 10:08am, Saeed Mirzamohammadi wrote:
...
> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index af14a567b493..f87c88ffa2f8 100644
> >
he actual memory.
>
> With this change the pages for holes inside a zone will get proper
> zone/node links and the pages that are not spanned by any node will get
> links to the adjacent zone/node.
Thanks for spending so much effort with patience to fix this.
Reviewed-by: Baoquan He
>
> Fixe
s. By the way, maybe you can remove John's 'Tested-by' since it
doesn't make much sense to test a document patch.
Acked-by: Baoquan He
>
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> ---
> Documentation/admin-guide/kdump/kdump.rst | 22 ---
> .../
ow if no
other people has concern or suggestion about it.
Anyway, ack this one.
Acked-by: Baoquan He
Thanks
Baoquan
>
> Suggested-by: Mike Rapoport
> Suggested-by: Baoquan He
> Signed-off-by: Chen Zhou
> ---
> arch/Kconfig| 3 +++
> arch/arm64/Kconfig | 1
; 32) && reserve_crashkernel_low()) {
> + if (crash_base >= CRASH_ADDR_LOW_MAX && reserve_crashkernel_low()) {
> memblock_free(crash_base, crash_size);
> return;
Acked-by: Baoquan He
> }
> --
> 2.20.1
>
On 02/18/21 at 03:31pm, Baoquan He wrote:
> On 01/30/21 at 03:10pm, Chen Zhou wrote:
> > We make the functions reserve_crashkernel[_low]() as generic for
> > x86 and arm64. Since reserve_crashkernel[_low]() implementations
> > are quite similar on other architectures as w
>
> So have CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL in arch/Kconfig and
> select this by X86 and ARM64.
>
> Suggested-by: Mike Rapoport
> Suggested-by: Baoquan He
> Signed-off-by: Chen Zhou
> ---
> arch/Kconfig| 3 +++
> arch/arm64/Kconfig | 1 +
> arch/x86/Kconfig|
On 01/30/21 at 03:10pm, Chen Zhou wrote:
> Move macro vmcore_elf_check_arch_cross from arch/x86/include/asm/kexec.h
> to arch/x86/include/asm/elf.h to fix the following compiling warning:
>
> make ARCH=i386
> In file included from arch/x86/kernel/setup.c:39:0:
>
> + else {
> + reserve_crashkernel();
> +#ifdef CONFIG_KEXEC_CORE
> + if (crashk_res.end > crashk_res.start)
> + insert_resource(_resource, _res);
> + if (crashk_low_res.end > crashk_low_res.start)
> + insert_resource(_resource, _low_res);
> +#endif
Acked-by: Baoquan He
> + }
>
> memblock_find_dma_reserve();
>
> --
> 2.20.1
>
tatic int __init reserve_crashkernel_low(void)
> return 0;
> }
>
> - low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
> CRASH_ADDR_LOW_MAX);
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, CRASH_ALIGN,
>
M with macro CRASH_ALIGN.
>
> Suggested-by: Dave Young
> Suggested-by: Baoquan He
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> ---
> arch/x86/include/asm/kexec.h | 3 +++
> arch/x86/kernel/setup.c | 5 +
> 2 files changed, 4 insertions(+), 4 deletions(-)
On 02/11/21 at 10:08am, Saeed Mirzamohammadi wrote:
> This adds crashkernel=auto feature to configure reserved memory for
> vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
> different kernel distributions and different archs based on their
> needs.
>
> Signed-off-by: Saeed
On 02/01/21 at 04:34pm, Mike Rapoport wrote:
> On Mon, Feb 01, 2021 at 07:26:05PM +0800, Baoquan He wrote:
> > On 02/01/21 at 10:32am, David Hildenbrand wrote:
> > >
> > > 2) In init_zone_unavailable_mem(), similar to round_up(max_pfn,
> > > PAGES_P
On 02/01/21 at 10:32am, David Hildenbrand wrote:
> On 30.01.21 23:10, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The physical memory on an x86 system starts at address 0, but this is not
> > always reflected in e820 map. For example, the BIOS can have e820 entries
> > like
> >
> > [
On 02/01/21 at 10:14am, David Hildenbrand wrote:
> On 11.01.21 20:40, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > There could be struct pages that are not backed by actual physical memory.
> > This can happen when the actual memory bank is not a multiple of
> > SECTION_SIZE or when an
nclude
> @@ -1180,6 +1181,7 @@ int kernel_kexec(void)
> machine_shutdown();
> }
>
> + kmsg_dump(KMSG_DUMP_SHUTDOWN);
> machine_kexec(kexec_image);
Looks good to me, thx.
Acked-by: Baoquan He
>
> #ifdef CONFIG_KEXEC_JUMP
> --
> 2.25.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
On 01/27/21 at 08:26pm, Mike Rapoport wrote:
> Hi Lukasz,
>
> On Wed, Jan 27, 2021 at 02:15:53PM +0100, Łukasz Majczak wrote:
> > Hi Mike,
> >
> > I have started bisecting your patch and I have figured out that there
> > might be something wrong with clamping - with comments out these lines
> >
atch 2 accodrding to David's comment.
Baoquan He (5):
mm: fix prototype warning from kernel test robot
mm: rename memmap_init() and memmap_init_zone()
mm: simplify parater of function memmap_init_zone()
mm: simplify parameter of setup_usemap()
mm: remove unneeded local variable in free_area_ini
,
| ^~~~
Fix it by adding the function declaration in include/linux/mm.h.
Since memmap_init_zone() has a generic version with '__weak',
the declaratoin in ia64 header file can be simply removed.
Signed-off-by: Baoquan He
Reported-by: kernel test robot
---
arch/ia64
The current memmap_init_zone() only handles memory region inside one zone,
actually memmap_init() does the memmap init of one zone. So rename both of
them accordingly.
Signed-off-by: Baoquan He
---
arch/ia64/mm/init.c | 6 +++---
include/linux/mm.h | 4 ++--
mm/memory_hotplug.c | 2 +-
mm
Parameter 'zone' has got needed information, let's remove other
unnecessary parameters.
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
Reviewed-by: David Hildenbrand
---
mm/page_alloc.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/mm
As David suggested, simply passing 'struct zone *zone' is enough. We can
get all needed information from 'struct zone*' easily.
Suggested-by: David Hildenbrand
Signed-off-by: Baoquan He
---
arch/ia64/mm/init.c | 12 +++-
include/linux/mm.h | 3 +--
mm/page_alloc.c | 24
Local variable 'zone_start_pfn' is not needed since there's only
one call site in free_area_init_core(). Let's remove it and pass
zone->zone_start_pfn directly to init_currently_empty_zone().
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
Reviewed-by: David Hildenbrand
---
On 01/22/21 at 09:55am, David Hildenbrand wrote:
> On 22.01.21 09:46, Baoquan He wrote:
> > On 01/22/21 at 09:40am, David Hildenbrand wrote:
> >> On 22.01.21 08:03, Baoquan He wrote:
> >>> Kernel test robot calling make with 'W=1' triggering warning like below
&g
On 01/22/21 at 09:40am, David Hildenbrand wrote:
> On 22.01.21 08:03, Baoquan He wrote:
> > Kernel test robot calling make with 'W=1' triggering warning like below
> > below for memmap_init_zone() function.
> >
> > mm/page_alloc.c:6259:23: warning: no previous prototype
x-mm/master ia64/next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Baoq
,
| ^~~~
Fix it by adding the function declaration in include/linux/mm.h.
Since memmap_init_zone() has a generic version with '__weak',
the declaratoin in ia64 header file can be simply removed.
Signed-off-by: Baoquan He
Reported-by: kernel test robot
---
arch
On 01/21/21 at 10:25am, Mike Rapoport wrote:
> On Thu, Jan 21, 2021 at 04:17:27PM +0800, Baoquan He wrote:
> > On 01/20/21 at 11:47pm, kernel test robot wrote:
> > > Hi Baoquan,
> > >
> > > I love your patch! Perhaps something to improve:
> > >
&
x-mm/master ia64/next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Baoq
return 0;
>
> out_err:
> - if (buf)
> - vfree(buf);
> -
> - if (dump)
> - vfree(dump);
> + vfree(buf);
> + vfree(dump);
Looks good, thx.
Acked-by: Baoquan He
Thanks
Baoquan
The current memmap_init_zone() only handles memory region inside one zone,
actually memmap_init() does the memmap init of one zone. So rename both of
them accordingly.
Signed-off-by: Baoquan He
---
arch/ia64/include/asm/pgtable.h | 2 +-
arch/ia64/mm/init.c | 6 +++---
include/linux
Parameter 'zone' has got needed information, let's remove other
unnecessary parameters.
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
Reviewed-by: David Hildenbrand
---
mm/page_alloc.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/mm
Local variable 'zone_start_pfn' is not needed since there's only
one call site in free_area_init_core(). Let's remove it and pass
zone->zone_start_pfn directly to init_currently_empty_zone().
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
Reviewed-by: David Hildenbrand
---
As David suggested, simply passing 'struct zone *zone' is enough. We can
get all needed information from 'struct zone*' easily.
Suggested-by: David Hildenbrand
Signed-off-by: Baoquan He
---
arch/ia64/include/asm/pgtable.h | 3 +--
arch/ia64/mm/init.c | 12 +++-
mm
pfn' of memmap_init() from patch 1 to patch 2
according to David's comment.
- Use the reverse Christmas tree style to reorder the local variables
in memmap_init_zone() in patch 2 accodrding to David's comment.
Baoquan He (4):
mm: rename memmap_init() and memmap_init_zone()
mm: simplify para
On 01/15/21 at 07:42pm, Baoquan He wrote:
> On 01/15/21 at 10:32am, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Hi,
> >
> > David noticed that we do some of memblock_reserve() calls after allocations
> > are possible:
> >
> > h
On 01/15/21 at 10:32am, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> David noticed that we do some of memblock_reserve() calls after allocations
> are possible:
>
> https://lore.kernel.org/lkml/6ba6bde3-1520-5cd0-f987-32d543f0b...@redhat.com
Thanks for CC-ing me, so I think the
On 01/11/21 at 10:16am, gre...@linuxfoundation.org wrote:
> On Fri, Jan 08, 2021 at 06:22:24PM +0800, Baoquan He wrote:
> > On 01/08/21 at 10:07am, HAGIO KAZUHITO(萩尾 一仁) wrote:
> > > Hi Baoquan,
> > >
> > > -Original Message-
> > > > O
On 01/08/21 at 10:07am, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Baoquan,
>
> -Original Message-
> > On 09/30/20 at 12:23pm, Alexander Egorenkov wrote:
> > > The offset of the field 'init_uts_ns.name' has changed
> > > since commit 9a56493f6942 ("uts: Use generic ns_common::count").
> >
> >
On 01/08/21 at 09:12am, Greg KH wrote:
> On Fri, Jan 08, 2021 at 11:32:48AM +0800, Baoquan He wrote:
> > On 09/30/20 at 12:23pm, Alexander Egorenkov wrote:
> > > The offset of the field 'init_uts_ns.name' has changed
> > > since commit 9a56493f6942 ("u
On 09/30/20 at 12:23pm, Alexander Egorenkov wrote:
> The offset of the field 'init_uts_ns.name' has changed
> since commit 9a56493f6942 ("uts: Use generic ns_common::count").
This patch is merged into 5.11-rc1, but we met the makedumpfile failure
of kdump test case in 5.10.0 kernel. Should affect
On 01/05/21 at 05:53pm, David Hildenbrand wrote:
> [...]
>
> > -void __meminit
> > -memmap_init_zone(unsigned long size, int nid, unsigned long zone,
> > -unsigned long start_pfn)
> > +void __meminit memmap_init_zone(struct zone *zone)
> > {
> > + unsigned long size =
On 01/05/21 at 05:49pm, David Hildenbrand wrote:
> On 05.01.21 08:47, Baoquan He wrote:
> > The current memmap_init_zone() only handles memory region inside one zone,
> > actually memmap_init() does the memmap init of one zone. So rename both of
> > them accordingly.
>
On 01/06/21 at 11:35am, Andrew Morton wrote:
> On Wed, 6 Jan 2021 14:49:35 +0800 Baoquan He wrote:
>
> > > Fixes: 9a1ac2288cf1 ("mm/memcontrol:rewrite mem_cgroup_page_lruvec()")
> >
> > ...
> >
> > Thanks for fixing this. We also encountered this
gt; {
> struct mem_cgroup *memcg = page_memcg(page);
>
> - VM_WARN_ON_ONCE_PAGE(!memcg, page);
> + VM_WARN_ON_ONCE_PAGE(!memcg && !mem_cgroup_disabled(), page);
> return mem_cgroup_lruvec(memcg, pgdat);
Thanks for fixing this. We also encountered this issue in kdump kernel
with the mainline 5.10 kernel since 'cgroup_disable=memory' is added.
Reviewed-by: Baoquan He
/zone_end_pfn.
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
arch/ia64/include/asm/pgtable.h | 2 +-
arch/ia64/mm/init.c | 6 +++---
include/linux/mm.h | 2 +-
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 24
Local variable 'zone_start_pfn' is not needed since there's only
one call site in free_area_init_core(). Let's remove it and pass
zone->zone_start_pfn directly to init_currently_empty_zone().
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
mm/page_alloc.c | 3 +--
1 file changed
As David suggested, simply passing 'struct zone *zone' is enough. We can
get all needed information from 'struct zone*' easily.
Suggested-by: David Hildenbrand
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
arch/ia64/include/asm/pgtable.h | 3 +--
arch/ia64/mm/init.c
Parameter 'zone' has got needed information, let's remove other
unnecessary parameters.
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
mm/page_alloc.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index
as v3.
No any change comparing with v2, except of adding Mike's 'Reviewed-by' tag.
V2 post is here:
https://lore.kernel.org/linux-mm/20201220082754.6900-1-...@redhat.com/
Baoquan He (4):
mm: rename memmap_init() and memmap_init_zone()
mm: simplify parater of function memmap_init_zone()
mm
On 12/23/20 at 10:05am, Baoquan He wrote:
> On 12/22/20 at 05:46pm, Andrew Morton wrote:
> > On Sun, 20 Dec 2020 16:27:49 +0800 Baoquan He wrote:
> >
> > > VMware reported the performance regression during memmap_init()
> > > invocation.
> > > And
p_init: iterate over memblock regions
rather that check each PFN")
Reported-by: Rahul Gopakumar
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
Cc: sta...@vger.kernel.org
---
arch/ia64/mm/init.c | 4 ++--
include/linux/mm.h | 5 +++--
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c |
0x00028000-0x00067f1f]
[0.070161] ACPI: PM-Timer IO Port: 0x408
Baoquan He (1):
mm: memmap defer init dosn't work as expected
arch/ia64/mm/init.c | 4 ++--
include/linux/mm.h | 5 +++--
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 8 +---
4 files changed, 11 insertions
On 12/22/20 at 05:46pm, Andrew Morton wrote:
> On Sun, 20 Dec 2020 16:27:49 +0800 Baoquan He wrote:
>
> > VMware reported the performance regression during memmap_init() invocation.
> > And they bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over
>
On 12/14/20 at 10:50am, Eric DeVolder wrote:
...
> The cell contents show the number of seconds it took for the system to
> process all of the 3840 memblocks. The value in parenthesis is the
> number of kdump unload-then-reload operations per second.
>
> 1 480GB DIMM 480 1GB DIMMs
>
p_init: iterate over memblock regions
rather that check each PFN")
Reported-by: Rahul Gopakumar
Signed-off-by: Baoquan He
Cc: sta...@vger.kernel.org
---
arch/ia64/mm/init.c | 4 ++--
include/linux/mm.h | 5 +++--
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 8 +---
4 files changed,
Local variable 'zone_start_pfn' is not needed since there's only
one call site in free_area_init_core(). Let's remove it and pass
zone->zone_start_pfn directly to init_currently_empty_zone().
Signed-off-by: Baoquan He
---
mm/page_alloc.c | 3 +--
1 file changed, 1 insertion(+), 2 deleti
As David suggested, simply passing 'struct zone *zone' is enough. We can
get all needed information from 'struct zone*' easily.
Suggested-by: David Hildenbrand
Signed-off-by: Baoquan He
---
arch/ia64/include/asm/pgtable.h | 3 +--
arch/ia64/mm/init.c | 12 +++-
mm
Parameter 'zone' has got needed information, let's remove other
unnecessary parameters.
Signed-off-by: Baoquan He
---
mm/page_alloc.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7a6626351ed7..7f0a917ab858 100644
/zone_end_pfn.
Signed-off-by: Baoquan He
---
arch/ia64/include/asm/pgtable.h | 2 +-
arch/ia64/mm/init.c | 6 +++---
include/linux/mm.h | 2 +-
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 24
5 files changed, 18
the
patch 1 is not changed in functionality in v2. And I haven't got a
ia64 machine to compile or test, will really appreciate if anyone can help
compile this patchset on one. This patchset is based on the latest next/master,
only did the basic test.
Baoquan He (5):
mm: memmap defer init d
On 12/14/20 at 01:04pm, Mike Rapoport wrote:
> On Mon, Dec 14, 2020 at 11:00:07AM +0100, David Hildenbrand wrote:
> > On 13.12.20 16:09, Baoquan He wrote:
> > > The current memmap_init_zone() only handles memory region inside one zone.
> > > Actually memmap_init() does
On 12/14/20 at 11:00am, David Hildenbrand wrote:
> On 13.12.20 16:09, Baoquan He wrote:
> > The current memmap_init_zone() only handles memory region inside one zone.
> > Actually memmap_init() does the memmap init of one zone. So rename both of
> > them accordingly.
>
.
Signed-off-by: Baoquan He
---
arch/ia64/mm/init.c | 6 +++---
include/linux/mm.h | 2 +-
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 16
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 27ca549ff47e
p_init: iterate over memblock regions
rather that check each PFN")
Signed-off-by: Baoquan He
Cc: sta...@vger.kernel.org
---
arch/ia64/mm/init.c | 4 ++--
include/linux/mm.h | 5 +++--
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 8 +---
4 files changed, 11 insertions(+), 8 dele
Patch
2/2 clean up the inappropriate name of memmap_init(), memmap_init_zone()
accordingly.
VMware helped do the testing on their VMware ESI platform. This patchset
is based on 5.10.0-rc7+, master branch of Linus's tree.
Baoquan He (2):
mm: memmap defer init dosn't work as expected
On 11/12/20 at 10:25am, Mike Rapoport wrote:
> On Wed, Nov 11, 2020 at 09:54:48PM +0800, Baoquan He wrote:
> > On 11/11/20 at 09:27pm, chenzhou wrote:
> > > Hi Baoquan,
> > ...
> > > >> #ifdef CONFIG_CRASH_DUMP
> > > >> static int _
On 11/11/20 at 09:27pm, chenzhou wrote:
> Hi Baoquan,
...
> >> #ifdef CONFIG_CRASH_DUMP
> >> static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> index 1c0f3e02f731..c55cee290bbb 100644
> >> --- a/arch/arm64/mm/mmu.c
Hi Zhou, Bhupesh
On 10/31/20 at 03:44pm, Chen Zhou wrote:
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which
> will fail when there is no enough low memory.
> 2. If reserving crashkernel above 4G, in this case, crash dump
> kernel will
On 10/31/20 at 03:44pm, Chen Zhou wrote:
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which
> will fail when there is no enough low memory.
> 2. If reserving crashkernel above 4G, in this case, crash dump
> kernel will boot failure because
On 10/31/20 at 03:44pm, Chen Zhou wrote:
> Move CRASH_ALIGN to header asm/kexec.h and replace the hard-coded
> alignment with macro CRASH_ALIGN in function reserve_crashkernel().
Seems you tell what you have done in this patch, but don't like adding
several more words to tell why it's done like
ost.localdomain
>
> Make the offset of the field 'uts_namespace.name' available
> in VMCOREINFO because tools like 'crash-utility' and
> 'makedumpfile' must be able to read it from crash dumps.
>
> Signed-off-by: Alexander Egorenkov
Ack, thanks.
Acked-by: Baoquan He
&g
ount
>
> Link:
> https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain
Seems there's some argument about the generic ns_common::count in the
thread of above link. While except of it, the adding the offset of
uts_namespace.name looks good to me.
Forgot CC-ing Jerry, add him.
On 09/23/20 at 10:26am, Baoquan He wrote:
> A regression failure of kdump kernel boot was reported on a HPE system.
> Bisect points at commit 387caf0b759ac43 ("iommu/amd: Treat per-device
> exclusion ranges as r/w unity-mapped regions") as
regions.
https://lists.linuxfoundation.org/pipermail/iommu/2019-November/040117.html
Signed-off-by: Baoquan He
---
drivers/iommu/amd/init.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index
Hi,
On 09/07/20 at 09:47pm, Chen Zhou wrote:
> To make the functions reserve_crashkernel[_low]() as generic,
> replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX.
>
> Signed-off-by: Chen Zhou
> ---
> arch/x86/kernel/setup.c | 11 ++-
> 1 file changed, 6 insertions(+), 5
On 08/21/20 at 10:31am, David Hildenbrand wrote:
> On 16.08.20 14:53, David Hildenbrand wrote:
> > For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff
> > maintained by me. This should go via the -mm tree.
> >
>
> @Andrew, can we give this a churn if there are no further
On 08/11/20 at 02:43pm, Mike Kravetz wrote:
> Here is a patch to do that. However, we are optimizing a return path in
> a race condition that we are unlikely to ever hit. I 'tested' it by
> allocating
> an 'extra' page and freeing it via this method in alloc_surplus_huge_page.
>
> From
On 08/11/20 at 08:54am, Michal Hocko wrote:
> On Tue 11-08-20 09:51:48, Baoquan He wrote:
> > On 08/10/20 at 05:19pm, Mike Kravetz wrote:
> > > On 8/9/20 7:17 PM, Baoquan He wrote:
> > > > On 08/07/20 at 05:12pm, Wei Yang wrote:
> > > >> Le
1 - 100 of 3124 matches
Mail list logo
