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
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 +++
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 +
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
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
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
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()
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)
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
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
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
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
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
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)
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
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(-)
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().
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
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
19 matches
Mail list logo