: memory management bits in arch/*
Hi,
There is a lot of similar and duplicated code in architecture specific bits of memory management.
For instance, as it was recently discussed at [1], most architectures have
#define GFP_KERNEL | __GFP_ZERO
for allocating page table pages and many of them use similar, if not identical, implementation of pte_alloc_one*().
But that's only the tip of the iceberg.
I've seen several early_alloc() or similarly called routines that do
if (slab_is_available())
return kazalloc()
else
return memblock_alloc()
Some other trivial examples are free_initmem(), free_initrd_mem() and, to some extent, mem_init(), but more generally there are a lot of similarities in arch/*/mm/.
More complex cases are per-cpu initialization, passing of memory topology to the generic MM, reservation of crash kernel, mmap of vdso etc. They are not really duplicated, but still are very similar in at least several architectures.
While factoring out the common code is an obvious step to take, I believe there is also room for refining arch <-> mm interface to avoid adding extra HAVE_ARCH_NO_BOOTMEM^w^wWHAT_NOT and then searching for ways to get rid of them.
This is particularly true for mm initialization. It evolved the way it's evolved, but now we can step back to black/white board and consider design that hopefully will avoid problems like [2].
As a side note, it might be also worth looking into dropping DISCONTIGMEM, although Kconfig still recommends to prefer it over SPARSEMEM [3].
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/[email protected]/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/Kconfig#n49
Signature · 2 lines
Sincerely yours, Mike.
Quoted 5 lines · Mike Rapoport
Hi,
There is a lot of similar and duplicated code in architecture specific bits of memory management.
Quoted 7 lines
For instance, as it was recently discussed at [1], most architectures have
#define GFP_KERNEL | __GFP_ZEROfor allocating page table pages and many of them use similar, if not identical, implementation of pte_alloc_one*().
As concluded earlier on that thread [1] apart from unifying allocation flags as GFP_PGTABLE there is also a need for generic implementation for standard page table page allocation/free functions like pte_alloc_one_[kernel]()/ pte_free_[kernel]() which can ensure that all page allocation/free goes through pgtable_page_ctor/dtor constructs and user page table allocation is accounted for it's memcg with __GFP_ACCOUNT.
IMHO zone stats for NR_PAGETABLE and memcg accounting for user page tables should not be arch specific and the semantics should be same for all.
Quoted 5 lines
But that's only the tip of the iceberg.
I've seen several
early_alloc()or similarly called routines that do
Quoted 8 lines
if (
slab_is_available())
returnkazalloc()
else
returnmemblock_alloc()Some other trivial examples are
free_initmem(),free_initrd_mem()and, to some extent,mem_init(), but more generally there are a lot of similarities inarch/*/mm/.
Agreed.
Quoted 6 lines
More complex cases are per-cpu initialization, passing of memory topology to the generic MM, reservation of crash kernel, mmap of vdso etc. They are not really duplicated, but still are very similar in at least several architectures.
Quoted 8 lines
While factoring out the common code is an obvious step to take, I believe there is also room for refining arch <-> mm interface to avoid adding extra HAVE_ARCH_NO_BOOTMEM^w^wWHAT_NOT and then searching for ways to get rid of them.
This is particularly true for mm initialization. It evolved the way it's evolved, but now we can step back to black/white board and consider design that hopefully will avoid problems like [2].
Factoring out common code one specific function at a time would be the right approach. As suggested during GFP_PGTABLE thread, first define a generic function and switch one arch at a time to use the generic one. This will give enough time for each platform to evaluate before subscribing to the new generic function. I would like to participate in this discussion.