Messages in this thread | | | Date | Mon, 7 Nov 2016 09:48:03 +0800 | From | Xishi Qiu <> | Subject | Re: [RFC][PATCH] mm: merge as soon as possible when pcp alloc/free |
| |
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?
Thanks, Xishi Qiu
> > . >
| |