From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f199.google.com (mail-yb0-f199.google.com [209.85.213.199]) by kanga.kvack.org (Postfix) with ESMTP id 713946B0069 for ; Sun, 6 Nov 2016 20:55:47 -0500 (EST) Received: by mail-yb0-f199.google.com with SMTP id d124so152667445ybf.2 for ; Sun, 06 Nov 2016 17:55:47 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com. [58.251.152.64]) by mx.google.com with ESMTPS id s9si13250049otb.240.2016.11.06.17.55.45 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 06 Nov 2016 17:55:46 -0800 (PST) Message-ID: <581FDD53.20804@huawei.com> Date: Mon, 7 Nov 2016 09:48:03 +0800 From: Xishi Qiu MIME-Version: 1.0 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 Sender: owner-linux-mm@kvack.org List-ID: 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 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 > > . > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org 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 > > . >