From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754908AbcG1JcG (ORCPT ); Thu, 28 Jul 2016 05:32:06 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:7225 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754721AbcG1Jb5 (ORCPT ); Thu, 28 Jul 2016 05:31:57 -0400 Message-ID: <5799C612.1050502@huawei.com> Date: Thu, 28 Jul 2016 16:45:06 +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: Michal Hocko CC: Tejun Heo , Ingo Molnar , Peter Zijlstra , LKML , Linux MM , Andy Lutomirski , Yisheng Xie Subject: Re: [RFC] can we use vmalloc to alloc thread stack if compaction failed References: <5799AF6A.2070507@huawei.com> <20160728072028.GC31860@dhcp22.suse.cz> <5799B741.8090506@huawei.com> <20160728075856.GE31860@dhcp22.suse.cz> In-Reply-To: <20160728075856.GE31860@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5799D0FB.008D,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 35d388b55539db0f7a014f4ae312d65f Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/7/28 15:58, Michal Hocko wrote: > On Thu 28-07-16 15:41:53, Xishi Qiu wrote: >> On 2016/7/28 15:20, Michal Hocko wrote: >> >>> On Thu 28-07-16 15:08:26, Xishi Qiu wrote: >>>> Usually THREAD_SIZE_ORDER is 2, it means we need to alloc 16kb continuous >>>> physical memory during fork a new process. >>>> >>>> If the system's memory is very small, especially the smart phone, maybe there >>>> is only 1G memory. So the free memory is very small and compaction is not >>>> always success in slowpath(__alloc_pages_slowpath), then alloc thread stack >>>> may be failed for memory fragment. >>> >>> Well, with the current implementation of the page allocator those >>> requests will not fail in most cases. The oom killer would be invoked in >>> order to free up some memory. >>> >> >> Hi Michal, >> >> Yes, it success in most cases, but I did have seen this problem in some >> stress-test. >> >> DMA free:470628kB, but alloc 2 order block failed during fork a new process. >> There are so many memory fragments and the large block may be soon taken by >> others after compact because of stress-test. >> >> --- dmesg messages --- >> 07-13 08:41:51.341 <4>[309805.658142s][pid:1361,cpu5,sManagerService]sManagerService: page allocation failure: order:2, mode:0x2000d1 > > Yes but this is __GFP_DMA allocation. I guess you have already reported > this failure and you've been told that this is quite unexpected for the > kernel stack allocation. It is your out-of-tree patch which just makes > things worse because DMA restricted allocations are considered "lowmem" > and so they do not invoke OOM killer and do not retry like regular > GFP_KERNEL allocations. Hi Michal, Yes, we add GFP_DMA, but I don't think this is the key for the problem. If we do oom-killer, maybe we will get a large block later, but there is enough free memory before oom(although most of them are fragments). I wonder if we can alloc success without kill any process in this situation. Maybe use vmalloc is a good way, but I don't know the influence. Thanks, Xishi Qiu