From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 102EDC4332F for ; Wed, 21 Dec 2022 21:23:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230395AbiLUVXo (ORCPT ); Wed, 21 Dec 2022 16:23:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234471AbiLUVXm (ORCPT ); Wed, 21 Dec 2022 16:23:42 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 965F123167 for ; Wed, 21 Dec 2022 13:23:41 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 14E97B8122F for ; Wed, 21 Dec 2022 21:23:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B761FC433D2; Wed, 21 Dec 2022 21:23:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1671657818; bh=5rMYzdxjFK43Cn1F8xRbvN704KPCx1d4gcGNLXxMzo4=; h=Date:To:From:Subject:From; b=SEJFcsAW61s2khDOdcqp/2P4mT5QqFvdb0zOChKp/Mdx+OhFeatQ4fBXftw/r36cg TWs/TdRh/dnJy1fBsNyBeRe9xIg72C6/5MpefIyUVHar4ImNyTbNYUTaJvDth6+zHA oFjvd37lwNgrgo7F04xWTJaLd1CUp4JLL1L2KoLQ= Date: Wed, 21 Dec 2022 13:23:38 -0800 To: mm-commits@vger.kernel.org, willy@infradead.org, roman.gushchin@linux.dev, oleksiy.avramchenko@sony.com, npiggin@gmail.com, lstoakes@gmail.com, hch@infradead.org, bhe@redhat.com, urezki@gmail.com, akpm@linux-foundation.org From: Andrew Morton Subject: + mm-vmalloc-avoid-of-calling-__find_vmap_area-twise-in-__vunmap.patch added to mm-unstable branch Message-Id: <20221221212338.B761FC433D2@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap() has been added to the -mm mm-unstable branch. Its filename is mm-vmalloc-avoid-of-calling-__find_vmap_area-twise-in-__vunmap.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-vmalloc-avoid-of-calling-__find_vmap_area-twise-in-__vunmap.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: "Uladzislau Rezki (Sony)" Subject: mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap() Date: Wed, 21 Dec 2022 18:44:52 +0100 Patch series "mm: vmalloc: Avoid of calling __find_vmap_area() twise in __vunmap()", v2. This patch (of 3): Currently __vunmap() path calls __find_vmap_area() two times. One on entry to check that area exists, second time inside remove_vm_area() function that also performs a new search of VA. In order to improvie it from a performance point of view we split remove_vm_area() into two new parts: - find_unlink_vmap_area() that does a search and unlink from tree; - __remove_vm_area() that does a removing but without searching. In this case there is no any functional change for remove_vm_area() whereas vm_remove_mappings(), where a second search happens, switches to the __remove_vm_area() variant where already detached VA is passed as a parameter, so there is no need to find it again. Performance wise, i use test_vmalloc.sh with 32 threads doing alloc free on a 64-CPUs-x86_64-box: perf without this patch: - 31.41% 0.50% vmalloc_test/10 [kernel.vmlinux] [k] __vunmap - 30.92% __vunmap - 17.67% _raw_spin_lock native_queued_spin_lock_slowpath - 12.33% remove_vm_area - 11.79% free_vmap_area_noflush - 11.18% _raw_spin_lock native_queued_spin_lock_slowpath 0.76% free_unref_page perf with this patch: - 11.35% 0.13% vmalloc_test/14 [kernel.vmlinux] [k] __vunmap - 11.23% __vunmap - 8.28% find_unlink_vmap_area - 7.95% _raw_spin_lock 7.44% native_queued_spin_lock_slowpath - 1.93% free_vmap_area_noflush - 0.56% _raw_spin_lock 0.53% native_queued_spin_lock_slowpath 0.60% __vunmap_range_noflush __vunmap() consumes around ~20% less CPU cycles on this test. Link: https://lkml.kernel.org/r/20221221174454.1085130-1-urezki@gmail.com Signed-off-by: Uladzislau Rezki (Sony) Reported-by: Roman Gushchin Cc: Baoquan He Cc: Christoph Hellwig Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Nicholas Piggin Cc: Oleksiy Avramchenko Signed-off-by: Andrew Morton --- mm/vmalloc.c | 66 +++++++++++++++++++++++++++++++------------------ 1 file changed, 42 insertions(+), 24 deletions(-) --- a/mm/vmalloc.c~mm-vmalloc-avoid-of-calling-__find_vmap_area-twise-in-__vunmap +++ a/mm/vmalloc.c @@ -1825,9 +1825,11 @@ static void free_vmap_area_noflush(struc unsigned long va_start = va->va_start; unsigned long nr_lazy; - spin_lock(&vmap_area_lock); - unlink_va(va, &vmap_area_root); - spin_unlock(&vmap_area_lock); + if (!list_empty(&va->list)) { + spin_lock(&vmap_area_lock); + unlink_va(va, &vmap_area_root); + spin_unlock(&vmap_area_lock); + } nr_lazy = atomic_long_add_return((va->va_end - va->va_start) >> PAGE_SHIFT, &vmap_lazy_nr); @@ -1871,6 +1873,19 @@ struct vmap_area *find_vmap_area(unsigne return va; } +static struct vmap_area *find_unlink_vmap_area(unsigned long addr) +{ + struct vmap_area *va; + + spin_lock(&vmap_area_lock); + va = __find_vmap_area(addr, &vmap_area_root); + if (va) + unlink_va(va, &vmap_area_root); + spin_unlock(&vmap_area_lock); + + return va; +} + /*** Per cpu kva allocator ***/ /* @@ -2591,6 +2606,20 @@ struct vm_struct *find_vm_area(const voi return va->vm; } +static struct vm_struct *__remove_vm_area(struct vmap_area *va) +{ + struct vm_struct *vm; + + if (!va || !va->vm) + return NULL; + + vm = va->vm; + kasan_free_module_shadow(vm); + free_unmap_vmap_area(va); + + return vm; +} + /** * remove_vm_area - find and remove a continuous kernel virtual area * @addr: base address @@ -2607,22 +2636,8 @@ struct vm_struct *remove_vm_area(const v might_sleep(); - spin_lock(&vmap_area_lock); - va = __find_vmap_area((unsigned long)addr, &vmap_area_root); - if (va && va->vm) { - struct vm_struct *vm = va->vm; - - va->vm = NULL; - spin_unlock(&vmap_area_lock); - - kasan_free_module_shadow(vm); - free_unmap_vmap_area(va); - - return vm; - } - - spin_unlock(&vmap_area_lock); - return NULL; + va = find_unlink_vmap_area((unsigned long) addr); + return __remove_vm_area(va); } static inline void set_area_direct_map(const struct vm_struct *area, @@ -2637,15 +2652,16 @@ static inline void set_area_direct_map(c } /* Handle removing and resetting vm mappings related to the vm_struct. */ -static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) +static void vm_remove_mappings(struct vmap_area *va, int deallocate_pages) { + struct vm_struct *area = va->vm; unsigned long start = ULONG_MAX, end = 0; unsigned int page_order = vm_area_page_order(area); int flush_reset = area->flags & VM_FLUSH_RESET_PERMS; int flush_dmap = 0; int i; - remove_vm_area(area->addr); + __remove_vm_area(va); /* If this is not VM_FLUSH_RESET_PERMS memory, no need for the below. */ if (!flush_reset) @@ -2690,6 +2706,7 @@ static void vm_remove_mappings(struct vm static void __vunmap(const void *addr, int deallocate_pages) { struct vm_struct *area; + struct vmap_area *va; if (!addr) return; @@ -2698,19 +2715,20 @@ static void __vunmap(const void *addr, i addr)) return; - area = find_vm_area(addr); - if (unlikely(!area)) { + va = find_unlink_vmap_area((unsigned long)addr); + if (unlikely(!va)) { WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n", addr); return; } + area = va->vm; debug_check_no_locks_freed(area->addr, get_vm_area_size(area)); debug_check_no_obj_freed(area->addr, get_vm_area_size(area)); kasan_poison_vmalloc(area->addr, get_vm_area_size(area)); - vm_remove_mappings(area, deallocate_pages); + vm_remove_mappings(va, deallocate_pages); if (deallocate_pages) { int i; _ Patches currently in -mm which might be from urezki@gmail.com are mm-vmalloc-avoid-of-calling-__find_vmap_area-twise-in-__vunmap.patch mm-vmalloc-switch-to-find_unlink_vmap_area-in-vm_unmap_ram.patch mm-vmalloc-replace-bug_on-by-warn_on_once.patch