From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f198.google.com (mail-yw0-f198.google.com [209.85.161.198]) by kanga.kvack.org (Postfix) with ESMTP id 8ECA96B02C3 for ; Tue, 18 Jul 2017 04:38:29 -0400 (EDT) Received: by mail-yw0-f198.google.com with SMTP id n8so11062716ywh.3 for ; Tue, 18 Jul 2017 01:38:29 -0700 (PDT) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com. [2607:f8b0:4002:c09::241]) by mx.google.com with ESMTPS id q133si401375ybq.242.2017.07.18.01.38.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 01:38:28 -0700 (PDT) Received: by mail-yb0-x241.google.com with SMTP id c184so528488yba.1 for ; Tue, 18 Jul 2017 01:38:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170717082945.GB12888@dhcp22.suse.cz> References: <1500276451-10492-1-git-send-email-zhaoyang.huang@spreadtrum.com> <20170717082945.GB12888@dhcp22.suse.cz> From: Zhaoyang Huang Date: Tue, 18 Jul 2017 16:38:27 +0800 Message-ID: Subject: Re: [PATCH v2] mm/vmalloc: terminate searching since one node found Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: zhaoyang.huang@spreadtrum.com, Andrew Morton , Ingo Molnar , zijun_hu , Vlastimil Babka , Thomas Garnier , "Kirill A. Shutemov" , Andrey Ryabinin , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Mon, Jul 17, 2017 at 4:29 PM, Michal Hocko wrote: > On Mon 17-07-17 15:27:31, Zhaoyang Huang wrote: >> From: Zhaoyang Huang >> >> 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 >> (2) > > This still doesn't answer questions posted for your previous version > http://lkml.kernel.org/r/20170717070024.GC7397@dhcp22.suse.cz > > Please note that is really important to describe _why_ the patch is > needed. What has changed can be easily read in the diff... > I did some test on an ARM64 platform and found that there is no great help nor regression for vmalloc. By more investigation, I find that the vmalloc area for 64bit arch is too huge to reach the end of the vmap_free_list, which have the new allocated area just grow up(seems no chance to use the rb tree). I will try to find a 32bit platform for more test. >> 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; >> + } >> if (tmp->va_start <= addr) >> break; >> n = n->rb_left; >> -- >> 1.9.1 >> >> -- >> 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/ . >> Don't email: email@kvack.org > > -- > Michal Hocko > SUSE Labs -- 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/ . Don't email: email@kvack.org