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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>