From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751716AbcKGBsp (ORCPT ); Sun, 6 Nov 2016 20:48:45 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:42272 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751187AbcKGBsh (ORCPT ); Sun, 6 Nov 2016 20:48:37 -0500 Message-ID: <581FDD53.20804@huawei.com> Date: Mon, 7 Nov 2016 09:48:03 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Anshuman Khandual CC: Andrew Morton , Vlastimil Babka , Mel Gorman , Michal Hocko , Johannes Weiner , Joonsoo Kim , "'Kirill A . Shutemov'" , Taku Izumi , Yisheng Xie , Linux MM , LKML Subject: Re: [RFC][PATCH] mm: merge as soon as possible when pcp alloc/free References: <581D9103.1000202@huawei.com> <581DD097.5060400@linux.vnet.ibm.com> In-Reply-To: <581DD097.5060400@linux.vnet.ibm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > . >