Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753675AbbLVFbd (ORCPT ); Tue, 22 Dec 2015 00:31:33 -0500 Received: from mail-pf0-f171.google.com ([209.85.192.171]:35812 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753644AbbLVFbb convert rfc822-to-8bit (ORCPT ); Tue, 22 Dec 2015 00:31:31 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3116\)) Subject: Re: [RFC] mm: change find_vma() function From: yalin wang In-Reply-To: <20151215115342.GB75130@black.fi.intel.com> Date: Tue, 22 Dec 2015 13:31:21 +0800 Cc: "Kirill A. Shutemov" , Oleg Nesterov , Andrew Morton , Chen Gang , mhocko@suse.com, kwapulinski.piotr@gmail.com, Andrea Arcangeli , dcashman@google.com, "open list:MEMORY MANAGEMENT" , linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <35FEEB7C-1C74-4BF9-B2F2-EDB48996BD4F@gmail.com> References: <1450090945-4020-1-git-send-email-yalin.wang2010@gmail.com> <20151214121107.GB4201@node.shutemov.name> <20151214175509.GA25681@redhat.com> <20151214211132.GA7390@node.shutemov.name> <5603C6DF-DDA5-4B57-9608-63335282B966@gmail.com> <20151215115342.GB75130@black.fi.intel.com> To: "Kirill A. Shutemov" X-Mailer: Apple Mail (2.3116) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1516 Lines: 43 > On Dec 15, 2015, at 19:53, Kirill A. Shutemov wrote: > > On Tue, Dec 15, 2015 at 02:41:21PM +0800, yalin wang wrote: >>> On Dec 15, 2015, at 05:11, Kirill A. Shutemov wrote: >>> Anyway, I don't think it's possible to gain anything measurable from this >>> optimization. >>> >> the advantage is that if addr don’t belong to any vma, we don’t need loop all vma, >> we can break earlier if we found the most closest vma which vma->end_add > addr, > > Do you have any workload which can demonstrate the advantage? > > — i add the log in find_vma() to see the call stack , it is very efficient in mmap() / munmap / do_execve() / get_unmaped_area() / mem_cgroup_move_task()->walk_page_range()->find_vma() call , in most time the loop will break after search about 7 vm, i don’t consider the cache pollution problem in this patch, yeah, this patch will check the vm_prev->vm_end for every loop, but this only happened when tmp->vm_end > addr , if you don’t not check this , you will continue to loop to check next rb , this will also pollute the cache , so the question is which one is better ? i don’t have a better method to test this . Any good ideas about this ? how to test it ? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/