From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx189.postini.com [74.125.245.189]) by kanga.kvack.org (Postfix) with SMTP id 0E2C46B13F0 for ; Thu, 2 Feb 2012 02:10:37 -0500 (EST) Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 2 Feb 2012 07:03:25 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1272feZ2707570 for ; Thu, 2 Feb 2012 18:02:44 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1277WQS003520 for ; Thu, 2 Feb 2012 18:07:32 +1100 Message-ID: <4F2A362A.3020006@linux.vnet.ibm.com> Date: Thu, 02 Feb 2012 15:07:22 +0800 From: Xiao Guangrong MIME-Version: 1.0 Subject: Re: [PATCH 5/5] mm: search from free_area_cache for the bigger size References: <4F101904.8090405@linux.vnet.ibm.com> <4F1019D3.8020709@linux.vnet.ibm.com> <20120201144401.af84e3a2.akpm@linux-foundation.org> In-Reply-To: <20120201144401.af84e3a2.akpm@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: William Irwin , linux-mm@kvack.org, LKML On 02/02/2012 06:44 AM, Andrew Morton wrote: > On Fri, 13 Jan 2012 19:47:31 +0800 > Xiao Guangrong wrote: > >> If the required size is bigger than cached_hole_size, we would better search >> from free_area_cache, it is more easier to get free region, specifically for >> the 64 bit process whose address space is large enough >> >> Do it just as hugetlb_get_unmapped_area_topdown() in arch/x86/mm/hugetlbpage.c > > Can this cause additional fragmentation of the virtual address region? > If so, what might be the implications of this? Hmm, i think it is not bad since we have cached_hole_size, and, this way is also used in other functions and architectures(arch_get_unmapped_area, hugetlb_get_unmapped_area_bottomup, hugetlb_get_unmapped_area_topdown......). -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ 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 S1753322Ab2BBHK3 (ORCPT ); Thu, 2 Feb 2012 02:10:29 -0500 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:40608 "EHLO e23smtp03.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752398Ab2BBHK2 (ORCPT ); Thu, 2 Feb 2012 02:10:28 -0500 Message-ID: <4F2A362A.3020006@linux.vnet.ibm.com> Date: Thu, 02 Feb 2012 15:07:22 +0800 From: Xiao Guangrong User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Andrew Morton CC: William Irwin , linux-mm@kvack.org, LKML Subject: Re: [PATCH 5/5] mm: search from free_area_cache for the bigger size References: <4F101904.8090405@linux.vnet.ibm.com> <4F1019D3.8020709@linux.vnet.ibm.com> <20120201144401.af84e3a2.akpm@linux-foundation.org> In-Reply-To: <20120201144401.af84e3a2.akpm@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit x-cbid: 12020121-6102-0000-0000-000000C1B59A Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/02/2012 06:44 AM, Andrew Morton wrote: > On Fri, 13 Jan 2012 19:47:31 +0800 > Xiao Guangrong wrote: > >> If the required size is bigger than cached_hole_size, we would better search >> from free_area_cache, it is more easier to get free region, specifically for >> the 64 bit process whose address space is large enough >> >> Do it just as hugetlb_get_unmapped_area_topdown() in arch/x86/mm/hugetlbpage.c > > Can this cause additional fragmentation of the virtual address region? > If so, what might be the implications of this? Hmm, i think it is not bad since we have cached_hole_size, and, this way is also used in other functions and architectures(arch_get_unmapped_area, hugetlb_get_unmapped_area_bottomup, hugetlb_get_unmapped_area_topdown......).