Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751504AbdGRJZq (ORCPT ); Tue, 18 Jul 2017 05:25:46 -0400 Received: from sender-pp-092.zoho.com ([135.84.80.237]:25308 "EHLO sender-pp-092.zoho.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbdGRJZo (ORCPT ); Tue, 18 Jul 2017 05:25:44 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:cc:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=GEDcD6uxL3x3bOBTVOVigX5MB1qU0HeGGnzwgAy2eRzJAutJEsjp5Elfh7v4XC0CRhxwTzjTdbaH L0Q0lSIk+Ep89UD15Xj7IPOftV2fHdCmvSgFEukDiAPj1A+gUdx+ Subject: Re: [PATCH v3] mm/vmalloc: terminate searching since one node found To: =?UTF-8?B?Wmhhb3lhbmcgSHVhbmcgKOm7hOacnemYsyk=?= References: <1500366424-5882-1-git-send-email-zhaoyang.huang@spreadtrum.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, zijun_hu@htc.com, Andrew Morton , Michal Hocko , Ingo Molnar , Vlastimil Babka , Thomas Garnier , "Kirill A. Shutemov" , Andrey Ryabinin , linux-mm@kvack.org, linux-kernel@vger.kernel.org From: zijun_hu Message-ID: <596DD399.3030906@zoho.com> Date: Tue, 18 Jul 2017 17:23:37 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit X-ZohoMailClient: External Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3087 Lines: 68 On 07/18/2017 04:31 PM, Zhaoyang Huang (?Ƴ???) wrote: > > It is no need to find the very beginning of the area within > alloc_vmap_area, which can be done by judging each node during the process > it seems the original code is wrote to achieve the following two purposes : A, the result vamp_area has the lowest available address in the required range [vstart, vend) B, it maybe update the cached vamp_area node info which can speedup other relative allocations it look redundant but conventional and necessary this approach maybe destroy the original purposes > For current approach, the worst case is that the starting node which be found > for searching the 'vmap_area_list' is close to the 'vstart', while the final > available one is round to the tail(especially for the left branch). > This commit have the list searching start at the first available node, which > will save the time of walking the rb tree'(1)' and walking the list'(2)'. > > vmap_area_root > / \ > tmp_next U > / > tmp > / > ... (1) > / > first(current approach) > @tmp_next is the next node of @tmp in the ordered list_head, not in the rbtree > vmap_area_list->...->first->...->tmp->tmp_next > (2) > > Signed-off-by: Zhaoyang Huang > --- > mm/vmalloc.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 34a1c3e..9a5c177 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -459,9 +459,18 @@ static struct vmap_area *alloc_vmap_area(unsigned long size, > > while (n) { > struct vmap_area *tmp; > + struct vmap_area *tmp_next; > tmp = rb_entry(n, struct vmap_area, rb_node); > + tmp_next = list_next_entry(tmp, list); > if (tmp->va_end >= addr) { > first = tmp; > + if (ALIGN(tmp->va_end, align) + size > + < tmp_next->va_start) { if @tmp node don't locate in the required rang [vstart, vend), but the right of the range it maybe satisfy this condition, even if it locate it locate within the range, it maybe don't have the lowest free address. if @tmp don't have the next node, tmp_next->va_start will cause NULL dereference > + addr = ALIGN(tmp->va_end, align); > + if (cached_hole_size >= size) > + cached_hole_size = 0; it seems a little rough to reset the @cached_hole_size by this way, it will caused the cached info is updated in the next allocation regardless the allocation arguments. > + goto found; > + } > if (tmp->va_start <= addr) > break; > n = n->rb_left; > -- > 1.9.1 >