Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp810139ybi; Fri, 12 Jul 2019 05:03:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqyyNMgyfPj/9hznibOA366jc4gmahmn8Xt0c8MCCkSkdIlqkU7Q10EThM9dWcwo9wGggMye X-Received: by 2002:a63:e54:: with SMTP id 20mr10259654pgo.244.1562933022585; Fri, 12 Jul 2019 05:03:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562933022; cv=none; d=google.com; s=arc-20160816; b=KxvYjUZQywIc8pk7m0cfy9DDe/LsTjxSvzwmjsSvkQSniy/2vTiO5HVYSpBfXjpOky meZQyBqO5Q+mijsEZHVZXJVZWPYUfIZFU6UhPI/1Wakqq4z3VWmqYL9sluKDF0alV9a/ JT9xl9JvzxbXNwSFN1IdX6y8KV5IdqTMZcuabQSxDQsRQuxHdFgKnx0cHHmgF7IrikLB evqOJcq722X4dz3kQbwOkJok1TozvY3+JcnURRJsP0CLhBXc6405az7TGWVIK6SdhIDz 2aKP8xTEkWWaggCdl0HzFEvmUnOA4ReNXG7tHJ5IokeGDkfBFu43pKDR8sBE6nN/Qovv wUlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=1N5T/DvjIbzKu60HNBBXne5dRJa1DkC2KbW+cEgIYvs=; b=X5nTuTf+3n9ZRaFxnZL10On8FGYIZ3I3KnHTGaV6qqoNvtBNRWDviDAuz+XHq71WYi 0D+rH/vG35Hqq3hxQpy7X0ifOKhB0vhDhdRwmT1FsVhso9bsTQh0wKGwuV7TVQowDwor EkvTaa8h2J8bzMJkW66tHDw6TPDeVLPB87gZw93faTEbXKNsnGL9Uxd3eh6Yu+O0EZCp cnaftanuhxDx1Nd+ytnAzpih24ytblL38C4diFSy7hLf8V/quyAWexHOojxTUWl06F2D tODmoVQmW0hlXfuftXmvW8DQwXuAMbIIp3+SLrJg2HANk1jrp89koGSrgiKETY/9MEuN t70Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DPXSuuA3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v11si7680924plo.223.2019.07.12.05.03.27; Fri, 12 Jul 2019 05:03:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DPXSuuA3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726986AbfGLMCv (ORCPT + 99 others); Fri, 12 Jul 2019 08:02:51 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:38651 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726250AbfGLMCu (ORCPT ); Fri, 12 Jul 2019 08:02:50 -0400 Received: by mail-pg1-f194.google.com with SMTP id z75so4453972pgz.5 for ; Fri, 12 Jul 2019 05:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1N5T/DvjIbzKu60HNBBXne5dRJa1DkC2KbW+cEgIYvs=; b=DPXSuuA3BhnztMcN3LH2s8P/GhVUIZ+INcZ8vH0qgqibYFB2TDvNG5V4bjJ5hB+roD 9EpihKRQWeERkyyQXrdjT8wWp/BDewlmTJ3r2t4MmzQW6ocAVC4lZ4JjuB1l4H46FKsa JQ4Y1J8oB8D4IZGUTPwPRPc+2tqj4g/+Zl5Wn8c5DGgduv8L++LeAt7lAsekZRaV6gZ1 IzKQmq6Yl7levcLSBipOot+VObYWOHgI4XgPSfKffhfRYX5cfC07p1ODC/jfobIFbNvS oiQYYr5f7Fw66slqU8MghTJuAYpLuSC+ClKCiB1aAR0qazH0j+v+zarzHF7/FQE2yxzp z6hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1N5T/DvjIbzKu60HNBBXne5dRJa1DkC2KbW+cEgIYvs=; b=Y1z8WApEiNiA3nZ6Ae4Z8wqHhdVVtZsi6tr/KeNKMQUqOkm5XaIxykXCrrIFgk4Vnb yO0O5wMgBYbLrWMTU4jXFWdNZematPVExzz37K7E1/jwPOIkdj0s1VVYfty0wdFiyQrw KDbWoddBN2zAz4oXPMPGbblw/qqmwBvs5rr6CqW23rIhwu3IHu5uYjnERf/6vkZvAjc8 ne/wX3+Kjg9vEyLSYEkh8t4bvOfOI79vnxMMLq7CLfWAtbspbS1IXcPVPBrfwI+WZsir uYN+xfajRPXdkEU6mHJw/WcWkHawR+wyhImhLUj/opWat5MlhVe1qYUfqBtiPKnvwwnN cjVg== X-Gm-Message-State: APjAAAUjzDdXXSi1usZAm8CH2JXj8PJc+sLF13bjhDfSSMbuQaJ+UyxF MsB+xQMuLhsi0WmNv5hPahZhaUvKYxjttg== X-Received: by 2002:a65:614a:: with SMTP id o10mr9920097pgv.407.1562932969685; Fri, 12 Jul 2019 05:02:49 -0700 (PDT) Received: from localhost.localdomain.localdomain ([2408:823c:c11:478:b8c3:8577:bf2f:2]) by smtp.gmail.com with ESMTPSA id a128sm4605496pfb.185.2019.07.12.05.02.43 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 12 Jul 2019 05:02:49 -0700 (PDT) From: Pengfei Li To: akpm@linux-foundation.org Cc: urezki@gmail.com, rpenyaev@suse.de, peterz@infradead.org, guro@fb.com, rick.p.edgecombe@intel.com, rppt@linux.ibm.com, aryabinin@virtuozzo.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 1/2] mm/vmalloc: do not keep unpurged areas in the busy tree Date: Fri, 12 Jul 2019 20:02:12 +0800 Message-Id: <20190712120213.2825-2-lpf.vector@gmail.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190712120213.2825-1-lpf.vector@gmail.com> References: <20190712120213.2825-1-lpf.vector@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Uladzislau Rezki (Sony)" The busy tree can be quite big, even though the area is freed or unmapped it still stays there until "purge" logic removes it. 1) Optimize and reduce the size of "busy" tree by removing a node from it right away as soon as user triggers free paths. It is possible to do so, because the allocation is done using another augmented tree. The vmalloc test driver shows the difference, for example the "fix_size_alloc_test" is ~11% better comparing with default configuration: sudo ./test_vmalloc.sh performance Summary: fix_size_alloc_test loops: 1000000 avg: 993985 usec Summary: full_fit_alloc_test loops: 1000000 avg: 973554 usec Summary: long_busy_list_alloc_test loops: 1000000 avg: 12617652 usec Summary: fix_size_alloc_test loops: 1000000 avg: 882263 usec Summary: full_fit_alloc_test loops: 1000000 avg: 973407 usec Summary: long_busy_list_alloc_test loops: 1000000 avg: 12593929 usec 2) Since the busy tree now contains allocated areas only and does not interfere with lazily free nodes, introduce the new function show_purge_info() that dumps "unpurged" areas that is propagated through "/proc/vmallocinfo". 3) Eliminate VM_LAZY_FREE flag. Signed-off-by: Uladzislau Rezki (Sony) --- mm/vmalloc.c | 51 ++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 42 insertions(+), 9 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 4fa8d84599b0..9eb700a2087b 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -329,7 +329,6 @@ EXPORT_SYMBOL(vmalloc_to_pfn); #define DEBUG_AUGMENT_PROPAGATE_CHECK 0 #define DEBUG_AUGMENT_LOWEST_MATCH_CHECK 0 -#define VM_LAZY_FREE 0x02 #define VM_VM_AREA 0x04 static DEFINE_SPINLOCK(vmap_area_lock); @@ -541,7 +540,7 @@ link_va(struct vmap_area *va, struct rb_root *root, static __always_inline void unlink_va(struct vmap_area *va, struct rb_root *root) { - if (WARN_ON(RB_EMPTY_NODE(&va->rb_node))) + if (RB_EMPTY_NODE(&va->rb_node)) return; if (root == &free_vmap_area_root) @@ -1167,7 +1166,11 @@ EXPORT_SYMBOL_GPL(unregister_vmap_purge_notifier); static void __free_vmap_area(struct vmap_area *va) { /* - * Remove from the busy tree/list. + * In most cases VA is not attached to the tree, but there + * are a few exceptions: + * + * - is linked only in case of pcpu, recovery part; + * - if radix_tree_preload gets failed, see new_vmap_block(). */ unlink_va(va, &vmap_area_root); @@ -1318,6 +1321,10 @@ static void free_vmap_area_noflush(struct vmap_area *va) { unsigned long nr_lazy; + 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); @@ -2137,14 +2144,13 @@ struct vm_struct *remove_vm_area(const void *addr) might_sleep(); - va = find_vmap_area((unsigned long)addr); + spin_lock(&vmap_area_lock); + va = __find_vmap_area((unsigned long)addr); if (va && va->flags & VM_VM_AREA) { struct vm_struct *vm = va->vm; - spin_lock(&vmap_area_lock); va->vm = NULL; va->flags &= ~VM_VM_AREA; - va->flags |= VM_LAZY_FREE; spin_unlock(&vmap_area_lock); kasan_free_shadow(vm); @@ -2152,6 +2158,8 @@ struct vm_struct *remove_vm_area(const void *addr) return vm; } + + spin_unlock(&vmap_area_lock); return NULL; } @@ -3431,6 +3439,22 @@ static void show_numa_info(struct seq_file *m, struct vm_struct *v) } } +static void show_purge_info(struct seq_file *m) +{ + struct llist_node *head; + struct vmap_area *va; + + head = READ_ONCE(vmap_purge_list.first); + if (head == NULL) + return; + + llist_for_each_entry(va, head, purge_list) { + seq_printf(m, "0x%pK-0x%pK %7ld unpurged vm_area\n", + (void *)va->va_start, (void *)va->va_end, + va->va_end - va->va_start); + } +} + static int s_show(struct seq_file *m, void *p) { struct vmap_area *va; @@ -3443,10 +3467,9 @@ static int s_show(struct seq_file *m, void *p) * behalf of vmap area is being tear down or vm_map_ram allocation. */ if (!(va->flags & VM_VM_AREA)) { - seq_printf(m, "0x%pK-0x%pK %7ld %s\n", + seq_printf(m, "0x%pK-0x%pK %7ld vm_map_ram\n", (void *)va->va_start, (void *)va->va_end, - va->va_end - va->va_start, - va->flags & VM_LAZY_FREE ? "unpurged vm_area" : "vm_map_ram"); + va->va_end - va->va_start); return 0; } @@ -3482,6 +3505,16 @@ static int s_show(struct seq_file *m, void *p) show_numa_info(m, v); seq_putc(m, '\n'); + + /* + * As a final step, dump "unpurged" areas. Note, + * that entire "/proc/vmallocinfo" output will not + * be address sorted, because the purge list is not + * sorted. + */ + if (list_is_last(&va->list, &vmap_area_list)) + show_purge_info(m); + return 0; } -- 2.21.0