From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751914AbcKGEvC (ORCPT ); Sun, 6 Nov 2016 23:51:02 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:46652 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750957AbcKGEvB (ORCPT ); Sun, 6 Nov 2016 23:51:01 -0500 Subject: Re: [RFC][PATCH] mm: merge as soon as possible when pcp alloc/free To: Xishi Qiu References: <581D9103.1000202@huawei.com> <581DD097.5060400@linux.vnet.ibm.com> <581FDD53.20804@huawei.com> Cc: Andrew Morton , Vlastimil Babka , Mel Gorman , Michal Hocko , Johannes Weiner , Joonsoo Kim , "'Kirill A . Shutemov'" , Taku Izumi , Yisheng Xie , Linux MM , LKML From: Anshuman Khandual Date: Mon, 7 Nov 2016 10:20:50 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <581FDD53.20804@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16110704-0044-0000-0000-000001F89FD8 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16110704-0045-0000-0000-000005E58B1A Message-Id: <5820082A.9080906@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-07_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611070092 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.