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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F79CC4332F for ; Fri, 23 Dec 2022 16:42:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E052900003; Fri, 23 Dec 2022 11:42:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 28F8C900002; Fri, 23 Dec 2022 11:42:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1311E900003; Fri, 23 Dec 2022 11:42:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 025D6900002 for ; Fri, 23 Dec 2022 11:42:37 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C102D1404FA for ; Fri, 23 Dec 2022 16:42:36 +0000 (UTC) X-FDA: 80274139512.19.BC369F8 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf15.hostedemail.com (Postfix) with ESMTP id F0EA0A000C for ; Fri, 23 Dec 2022 16:42:34 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FAAIHQRB; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671813755; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=t9lDo4zcGBZtU9GRroIegeo4m6+vEehlc1gjHamKTDU=; b=5dRWsa4EvP7S2HRcStNZmqRkPWSlT3P2coyt00kTBn/ffbENJSO0JV/40AMaq9lw9w3YOT EMikekcuppJN+Iwn9FeT4DjkeVuK00gS20AD1VOFqpf2onwb3dsKq9L6u4Qi6VByCCLsdA UcfK+K6doisdUrjOX2zlgGNEy1zZy0k= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FAAIHQRB; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671813755; a=rsa-sha256; cv=none; b=EU6UzfUPJDlpYIeorC+DsrVdOxc5+SQAGZ/yKv2wKGs8ovGpWpI/siKbNv5jhjYkEDhr6Q p3vnijE8p59qEfH+ZRlGCQBYr62U7UHVm2hZsyD5foTmkc/k1VrczzWrq/00sJMIZMrByh 4KZ4uYbPT8kq1rYpwtP9mlQYgEo5jTc= Received: by mail-lf1-f42.google.com with SMTP id y25so7685830lfa.9 for ; Fri, 23 Dec 2022 08:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=t9lDo4zcGBZtU9GRroIegeo4m6+vEehlc1gjHamKTDU=; b=FAAIHQRB2etfhMJmLpqgmPiMBIU7ZSYuLQisxWtz5Np+In9WlwqAmoG1wN+qGNZK7q vLMXcpydpKcbIXzszc7/Y1qWC1WqBq7T/fGzlWqdID5Z6C2E1hzqoK4HZoISXzJGTwJZ qffxr73ZIhUjsraktJEj0DX+LSUjgUzDQGapjaFksOCTGOfrVlpurv/gxhN8QEG/ztvr WIeBvZvLEuQU1uUeBwOCqILu5WCmKmN3SbTOddd3968+Y8lLOUGaZy9O9MN95IodKbCM n3zHEGdH/NtqcwrAmd3m96wqU+Opg30f+n0L26V/wh9ky9Pl65Oc+JZPu0utW9Frq8Ig t6Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=t9lDo4zcGBZtU9GRroIegeo4m6+vEehlc1gjHamKTDU=; b=rr1DHAE/BqWgld3CqfjeRlLGkxuy8q0vDRfKO7SqGk05UypRfX1v36xQY2ec2MztBj JvpB/0Ruu8DzKr8sEoD32P6wixklbFLDPlPifG30Wa6GWZNnpYDMiiE81aZwSvL6Hzia n70SNIb09irA3TIOWnkvg+2Z+z6gwMvgPWzabhkWJFnbFVYuRR0UB41duWtOG5H3fMao DOSgy7Undcj5XX2GSP4jRuMo5omLzuz7oRNOCafgrqsLxg93URN6RY85lFl/6FpmfNmx 0tAKniXZzolPnSe3kjYaD1CUz3RSkcnMuhPp+SZ3n7qmtCFpVxssPI91wsE0dHWQXVnV bgtQ== X-Gm-Message-State: AFqh2kr42nQgJNYUJ3vstSFEyi4Ne5b1jKMhCLOV6x28qyI/xwlI5chu crnnZKeH8WN8ycXRJW3lLkM= X-Google-Smtp-Source: AMrXdXuaxUT8SetoijsAbGHV5bYJ3kakBadFf2fWOY27M5lnMECNlNHb/T1mFqD3AXjMkVB5IQTrdA== X-Received: by 2002:a05:6512:3d9f:b0:4a4:68b7:f878 with SMTP id k31-20020a0565123d9f00b004a468b7f878mr4054721lfv.28.1671813753442; Fri, 23 Dec 2022 08:42:33 -0800 (PST) Received: from pc636 (host-90-233-218-120.mobileonline.telia.com. [90.233.218.120]) by smtp.gmail.com with ESMTPSA id o1-20020ac25e21000000b004979db5aa5bsm584933lfg.223.2022.12.23.08.42.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Dec 2022 08:42:33 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 23 Dec 2022 17:42:30 +0100 To: Lorenzo Stoakes Cc: "Uladzislau Rezki (Sony)" , Andrew Morton , linux-mm@kvack.org, LKML , Baoquan He , Christoph Hellwig , Matthew Wilcox , Nicholas Piggin , Oleksiy Avramchenko , Roman Gushchin Subject: Re: [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Message-ID: References: <20221222190022.134380-1-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: F0EA0A000C X-Stat-Signature: g8fst5kqky4wxooa3qubqe495wc3bq81 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1671813754-127280 X-HE-Meta: U2FsdGVkX1/mNIPnxXlQUwcO3Kf7f4w3Lg+5TJFF8E+Gh1ZPW7GuPiiFpQ7PWh/cCLjozHdf2xDlJ6G0vtsFJ6GuoRSkQQ1HPfmjZJy0rStwFYAul1ypp3rI9jLgrefiJam9I/4g6ryeHaUdmVvGGPtGuOYvuM44XvjDa9lGRrWMuHWI3burhuLN4K+tI4wmork0WAiVJGcxvoPBNOVFJg96j7WDFT2mJjmLRFh8A7poW+RqxjWBiBa81DLgNjbK4SM78B7lXrI5+HeOIjzYjJPjzdb4s57wLUmeSy3Jgf/+A78pEmx602Qt7BzqEYCJmK9SMmwssnjIezAlgHRc53a2tBbYno0TsP0BYNu38I1Wsrq+8N6c5vVGEBdNM5E/n1oFZkAVbE7TQzXqEy2Cff9E6armRZg4L/YebGqJ8aRIlc1pfAjhzoILE5yx22P6RqkF1Egr1ajvZLa1alIsQ/1VIgv07g2mBALkezW046zjmkzv6uxQ1Glg6qfr8Qe/bkUFsVlZ5bNelRKAS36ZWYBaNAmZGNnrBk9Ur7ven7/9fgFdpHRNiJVZvEblXIAPLalsYkxuL2Em2SCyrGs9Jk5dqUU8xKoJo/irz3k8Qh/zpu/lDsU5+OXHkZy6T7NuQv/Jbnwci/cGWJ5h9d06vU1Z02cdR3A1bPWTY/tEpIfkRFaEVpsAKs+Gj4yG4A47O9t5L6FI89v81o1dzJrKpM3uEINT0JMzC8546q4ca9wnSjCylbG12BC4kL3o+RDFfCrH3ccCFucFj1sDRcPGawATa5VRoydFpZibz5IqlcZyKcG2tlYplIZ2khgoc+nUHUipqdmytf56LKjojSw7Ii3+6JHjv858pknuq2CB/Qw+guN2iRpwXDPnjMco9a0GHmojbX+Kct2GCqoGNhBSqduSNIy5pLOx0lvEQVsNUan+vMplFwDVEs/p7aAevGHsV15hFXSmEcD0OBXeWbr 7HiaHxqo xHCdxbLeFwtephPLoHtv6cazdp6uYAfqqR20RKWqpUUDerhIQa6YHA72vQZbNFwXAT6E+iVVSZBaUsE/bddV0uKeyjoAm8881pk0vPNSem7+9lV5Vu6xyfOydYub2eG/t1hF9YDXAClaxriM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Dec 22, 2022 at 08:06:11PM +0000, Lorenzo Stoakes wrote: > n Thu, Dec 22, 2022 at 08:00:20PM +0100, Uladzislau Rezki (Sony) wrote: > > Currently the __vunmap() path calls __find_vmap_area() twice. Once on > > entry to check that the area exists, then inside the remove_vm_area() > > function which also performs a new search for the 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 removes 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 the 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. > > > > v2 -> v3: > > - update commit message; > > - rename the vm_remove_mappings() to the va_remove_mappings(); > > - move va-unlinking to the callers so the free_vmap_area_noflush() > > now expects a VA that has been disconnected; > > - eliminate a local variable in the remove_vm_area(). > > > > Reported-by: Roman Gushchin > > Signed-off-by: Uladzislau Rezki (Sony) > > --- > > mm/vmalloc.c | 77 ++++++++++++++++++++++++++++++++-------------------- > > 1 file changed, 47 insertions(+), 30 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 9e30f0b39203..eb91ecaa7277 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -1815,9 +1815,9 @@ static void drain_vmap_area_work(struct work_struct *work) > > } > > > > /* > > - * Free a vmap area, caller ensuring that the area has been unmapped > > - * and flush_cache_vunmap had been called for the correct range > > - * previously. > > + * Free a vmap area, caller ensuring that the area has been unmapped, > > + * unlinked and flush_cache_vunmap had been called for the correct > > + * range previously. > > */ > > static void free_vmap_area_noflush(struct vmap_area *va) > > { > > @@ -1825,9 +1825,8 @@ static void free_vmap_area_noflush(struct vmap_area *va) > > 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 (WARN_ON_ONCE(!list_empty(&va->list))) > > + return; > > > > nr_lazy = atomic_long_add_return((va->va_end - va->va_start) >> > > PAGE_SHIFT, &vmap_lazy_nr); > > @@ -1871,6 +1870,19 @@ struct vmap_area *find_vmap_area(unsigned long addr) > > 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 ***/ > > > > /* > > @@ -2015,6 +2027,10 @@ static void free_vmap_block(struct vmap_block *vb) > > tmp = xa_erase(&vmap_blocks, addr_to_vb_idx(vb->va->va_start)); > > BUG_ON(tmp != vb); > > > > + spin_lock(&vmap_area_lock); > > + unlink_va(vb->va, &vmap_area_root); > > + spin_unlock(&vmap_area_lock); > > + > > free_vmap_area_noflush(vb->va); > > kfree_rcu(vb, rcu_head); > > } > > @@ -2591,6 +2607,20 @@ struct vm_struct *find_vm_area(const void *addr) > > 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 > > @@ -2603,26 +2633,10 @@ struct vm_struct *find_vm_area(const void *addr) > > */ > > struct vm_struct *remove_vm_area(const void *addr) > > { > > - struct vmap_area *va; > > - > > 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; > > + return __remove_vm_area( > > + find_unlink_vmap_area((unsigned long) addr)); > > } > > > > static inline void set_area_direct_map(const struct vm_struct *area, > > @@ -2636,16 +2650,17 @@ static inline void set_area_direct_map(const struct vm_struct *area, > > set_direct_map(area->pages[i]); > > } > > > > -/* Handle removing and resetting vm mappings related to the vm_struct. */ > > -static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) > > +/* Handle removing and resetting vm mappings related to the VA's vm_struct. */ > > +static void va_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 +2705,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) > > static void __vunmap(const void *addr, int deallocate_pages) > > { > > struct vm_struct *area; > > + struct vmap_area *va; > > > > if (!addr) > > return; > > @@ -2698,19 +2714,20 @@ static void __vunmap(const void *addr, int deallocate_pages) > > 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); > > + va_remove_mappings(va, deallocate_pages); > > > > if (deallocate_pages) { > > int i; > > -- > > 2.30.2 > > > > All looks good to me! Great work! Feel free to add the below to all patches in series:- > > Reviewed-by: Lorenzo Stoakes > Added :) Thank you for review! -- Uladzislau Rezki