On 11/07/2016 07:18 AM, Xishi Qiu wrote: > On 2016/11/5 20:29, Anshuman Khandual wrote: > >> On 11/05/2016 01:27 PM, Xishi Qiu 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. >> >> The idea of PCP is to have a fast allocation mechanism which does not depend >> on an interrupt safe spin lock for every allocation. I am not very familiar >> with this part of code but the following documentation from Mel Gorman kind >> of explains that the this type of fragmentation problem which you might be >> observing as one of the limitations of PCP mechanism. >> >> https://www.kernel.org/doc/gorman/html/understand/understand009.html >> "Per CPU page list" sub header. >> > > "The last potential problem is that buddies of newly freed pages could exist > in other pagesets leading to possible fragmentation problems." > So we should not change it, and this is a known issue, right? Seems like that. -- 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>