[LSF/MM TOPIC]: memory management bits in arch/*

[LSF/MM TOPIC]: memory management bits in arch/*

[Mike Rapoport]

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/1547619692-7946-1-git-send-email-anshuman.khandual@arm.com/
[2] https://lore.kernel.org/lkml/20190114082416.30939-1-mhocko@kernel.org/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/Kconfig#n49

-- 
Sincerely yours,
Mike.

Re: [LSF/MM TOPIC]: memory management bits in arch/*

[Anshuman Khandual]

On 01/28/2019 12:37 PM, Mike Rapoport wrote:
> 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*().

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.

>
> 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/.

Agreed.

> 
> 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].

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.