Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751323AbdGQJEv (ORCPT ); Mon, 17 Jul 2017 05:04:51 -0400 Received: from sender-pp-092.zoho.com ([135.84.80.237]:25466 "EHLO sender-pp-092.zoho.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbdGQJEu (ORCPT ); Mon, 17 Jul 2017 05:04:50 -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=L4gkA44YRgj1zxwvGmt8giHkJnCFccXFyVkoLLnhaP/jk0qBn35boh65955g/fvX69/F3mdUZ3Z3 KZdNGBuFCJ9jOJgzUSNw0ho8eEQULMRu+lYEgd7RgZfMpuycMw8X Subject: Re: [PATCH v2] mm/vmalloc: terminate searching since one node found To: Zhaoyang Huang References: <596C7924.1010207@zoho.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, zijun_hu@htc.com From: zijun_hu Message-ID: <596C7D99.5040208@zoho.com> Date: Mon, 17 Jul 2017 17:04:25 +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: <596C7924.1010207@zoho.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ZohoMailClient: External Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2670 Lines: 64 On 07/17/2017 04:45 PM, zijun_hu wrote: > On 07/17/2017 04:07 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 >> >> 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 >> / (1) >> tmp >> / >> ... >> / >> first(current approach) >> >> vmap_area_list->...->first->...->tmp->tmp_next > > the original code can ensure the following two points : > A, the result vamp_area has the lowest available address in the range [vstart, vend) > B, it can maintain the cached vamp_area node rightly which can speedup relative allocation > i suspect this patch maybe destroy the above two points >> (2) >> >> Signed-off-by: Zhaoyang Huang >> --- >> mm/vmalloc.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index 34a1c3e..f833e07 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -459,9 +459,16 @@ 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) { >> + addr = ALIGN(tmp->va_end, align); >> + goto found; >> + } > is the aim vamp_area the lowest available one if the goto occurs ? > it will bypass the latter cached vamp_area info cached_hole_size update possibly if the goto occurs it think the aim area maybe don't locates the required range [vstart, vend) possibly. >> if (tmp->va_start <= addr) >> break; >> n = n->rb_left; >> -- >> 1.9.1 >> >