Re: [PATCH v4 06/11] perf dso: Add support for reading the e_machine type for a dso

2025-03-06 Thread Ian Rogers
On Thu, Mar 6, 2025 at 5:22 PM Namhyung Kim wrote: > > On Mon, Mar 03, 2025 at 09:03:00PM -0800, Ian Rogers wrote: > > For ELF file dsos read the e_machine from the ELF header. For kernel > > types assume the e_machine matches the perf tool. In other cases > > return EM_NONE. > > > > Signed-off-by

Re: [PATCH v4 06/11] perf dso: Add support for reading the e_machine type for a dso

2025-03-06 Thread Namhyung Kim
On Mon, Mar 03, 2025 at 09:03:00PM -0800, Ian Rogers wrote: > For ELF file dsos read the e_machine from the ELF header. For kernel > types assume the e_machine matches the perf tool. In other cases > return EM_NONE. > > Signed-off-by: Ian Rogers > --- > tools/perf/util/dso.c | 54 +++

Re: [PATCH v4 02/11] perf dso: kernel-doc for enum dso_binary_type

2025-03-06 Thread Namhyung Kim
On Mon, Mar 03, 2025 at 09:02:56PM -0800, Ian Rogers wrote: > There are many and non-obvious meanings to the dso_binary_type enum > values. Add kernel-doc to speed interpretting their meanings. > > Signed-off-by: Ian Rogers > --- > tools/perf/util/dso.h | 53 +

[PATCH 12/13] arch, mm: introduce arch_mm_preinit

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" Currently, implementation of mem_init() in every architecture consists of one or more of the following: * initializations that must run before page allocator is active, for instance swiotlb_init() * a call to memblock_free_all() to release all the memory to th

Re: [PATCH 00/13] arch, mm: reduce code duplication in mem_init()

2025-03-06 Thread Andrew Morton
On Thu, 6 Mar 2025 20:51:10 +0200 Mike Rapoport wrote: > Every architecture has implementation of mem_init() function and some > even more than one. All these release free memory to the buddy > allocator, most of them set high_memory to the end of directly > addressable memory and many of them s

Re: [PATCH 00/13] arch, mm: reduce code duplication in mem_init()

2025-03-06 Thread Dave Hansen
On 3/6/25 10:51, Mike Rapoport wrote: > 53 files changed, 151 insertions(+), 618 deletions(-) > delete mode 100644 arch/x86/include/asm/numa_32.h > delete mode 100644 arch/x86/mm/highmem_32.c Holy cow, nice work. For the x86 bits: Acked-by: Dave Hansen

[PATCH 13/13] arch, mm: make releasing of memory to page allocator more explicit

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" The point where the memory is released from memblock to the buddy allocator is hidden inside arch-specific mem_init()s and the call to memblock_free_all() is needlessly duplicated in every artiste cure and after introduction of arch_mm_preinit() hook, mem_init()

[PATCH 07/13] s390: make setup_zero_pages() use memblock

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" Allocating the zero pages from memblock is simpler because the memory is already reserved. This will also help with pulling out memblock_free_all() to the generic code and reducing code duplication in arch::mem_init(). Signed-off-by: Mike Rapoport (Microsoft)

[PATCH 11/13] arch, mm: streamline HIGHMEM freeing

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" All architectures that support HIGHMEM have their code that frees high memory pages to the buddy allocator while __free_memory_core() is limited to freeing only low memory. There is no actual reason for that. The memory map is completely ready by the time memblo

[PATCH 10/13] arch, mm: set high_memory in free_area_init()

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" high_memory defines upper bound on the directly mapped memory. This bound is defined by the beginning of ZONE_HIGHMEM when a system has high memory and by the end of memory otherwise. All this is known to generic memory management initialization code that can se

[PATCH 09/13] arch, mm: set max_mapnr when allocating memory map for FLATMEM

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" max_mapnr is essentially the size of the memory map for systems that use FLATMEM. There is no reason to calculate it in each and every architecture when it's anyway calculated in alloc_node_mem_map(). Drop setting of max_mapnr from architecture code and set it o

[PATCH 08/13] xtensa: split out printing of virtual memory layout to a function

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" This will help with pulling out memblock_free_all() to the generic code and reducing code duplication in arch::mem_init(). Signed-off-by: Mike Rapoport (Microsoft) --- arch/xtensa/mm/init.c | 97 ++- 1 file changed, 50 i

[PATCH 06/13] nios2: move pr_debug() about memory start and end to setup_arch()

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" This will help with pulling out memblock_free_all() to the generic code and reducing code duplication in arch::mem_init(). Signed-off-by: Mike Rapoport (Microsoft) --- arch/nios2/kernel/setup.c | 2 ++ arch/nios2/mm/init.c | 2 -- 2 files changed, 2 inser

[PATCH 05/13] MIPS: make setup_zero_pages() use memblock

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" Allocating the zero pages from memblock is simpler because the memory is already reserved. This will also help with pulling out memblock_free_all() to the generic code and reducing code duplication in arch::mem_init(). Signed-off-by: Mike Rapoport (Microsoft)

[PATCH 04/13] MIPS: consolidate mem_init() for NUMA machines

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" Both MIPS systems that support numa (loongsoon3 and sgi-ip27) have identical mem_init() for NUMA case. Move that into arch/mips/mm/init.c and drop duplicate per-machine definitions. Signed-off-by: Mike Rapoport (Microsoft) --- arch/mips/loongson64/numa.c

[PATCH 03/13] hexagon: move initialization of init_mm.context init to paging_init()

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" This will help with pulling out memblock_free_all() to the generic code and reducing code duplication in arch::mem_init(). Signed-off-by: Mike Rapoport (Microsoft) --- arch/hexagon/mm/init.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-)

[PATCH 02/13] csky: move setup_initrd() to setup.c

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" Memory used by initrd should be reserved as soon as possible before there any memblock allocations that might overwrite that memory. This will also help with pulling out memblock_free_all() to the generic code and reducing code duplication in arch::mem_init().

[PATCH 01/13] arm: mem_init: use memblock_phys_free() to free DMA memory on SA1111

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" This will help to pull out memblock_free_all() to generic code. Signed-off-by: Mike Rapoport (Microsoft) --- arch/arm/mm/init.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 5345d21889

[PATCH 00/13] arch, mm: reduce code duplication in mem_init()

2025-03-06 Thread Mike Rapoport
From: "Mike Rapoport (Microsoft)" Hi, Every architecture has implementation of mem_init() function and some even more than one. All these release free memory to the buddy allocator, most of them set high_memory to the end of directly addressable memory and many of them set max_mapnr for FLATMEM