Re: [RFC][PATCH] mm: merge as soon as possible when pcp alloc/free

[Andrew Morton]

On Sat, 5 Nov 2016 15:57:55 +0800 Xishi Qiu <qiuxishi@xxxxxxxxxx> wrote:

> Usually the memory of android phones is very small, so after a long
> running, the fragment is very large. Kernel stack which called by
> alloc_thread_stack_node() usually alloc 16K memory, and it failed
> frequently.
> 
> However we have CONFIG_VMAP_STACK now, but it do not support arm64,
> and maybe it has some regression because of vmalloc, it need to
> find an area and create page table dynamically, this will take a short
> time.
> 
> I think we can merge as soon as possible when pcp alloc/free to reduce
> fragment. The pcp page is hot page, so free it will cause cache miss,
> I use perf to test it, but it seems the regression is not so much, maybe
> it need to test more. Any reply is welcome.

per-cpu pages may not be worth the effort on such systems - probably
benefit is small.  I discussed this with Mel a few years ago and I
think he did some testing, but I forget the results?

Anyway, if per-cpu pages are causing problems then perhaps we should
have a Kconfig option which simply eliminates them: free these pages
direct into the buddy.  If the resulting code is clean-looking and the
performance testing on small systems shows decent results then that
should address the issues you're seeing.