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

[Anshuman Khandual <anshuman.khandual@arm.com>]

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.