From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752772AbcKGXpi (ORCPT ); Mon, 7 Nov 2016 18:45:38 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:46276 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751762AbcKGXpe (ORCPT ); Mon, 7 Nov 2016 18:45:34 -0500 Date: Mon, 7 Nov 2016 15:45:32 -0800 From: Andrew Morton To: Xishi Qiu Cc: 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 Message-Id: <20161107154532.e3573bc08324e24aad6d1e26@linux-foundation.org> In-Reply-To: <581D9103.1000202@huawei.com> References: <581D9103.1000202@huawei.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 5 Nov 2016 15:57:55 +0800 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. per-cpu pages may not be worth the effort on such systems - probably benefit is small. I discussed this with Mel a few years ago and I think he did some testing, but I forget the results? Anyway, if per-cpu pages are causing problems then perhaps we should have a Kconfig option which simply eliminates them: free these pages direct into the buddy. If the resulting code is clean-looking and the performance testing on small systems shows decent results then that should address the issues you're seeing.