From nobody Sun Dec 14 12:17:05 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67E521E49F for ; Fri, 18 Apr 2025 22:37:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015834; cv=none; b=B6WM24bEEmX0GgOR4WUDQdWQRO46f6R45VkNsd3j09RY+b8ojWdkZra0lSSg+Cf1SqVQRiCjcepSXhZaEaEymDPqFv0ATmTRIZkSKWNtBjf8yxyB+pnNZ/IiIdpuMV/0kyg94k1u5R+Y+xxHOu+0CFGyCwwJ7MWBfKW6o6uaS/M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015834; c=relaxed/simple; bh=g4ihXMSwKPIoA2h8mD/JezA0Y0czIKb723cLWShfivc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=UGybXbw2tHRfYjXzhXASZpuehSHSCYKudB9moDRz/XbGCvYpV9zkvcJpN7TBiKml7x6Mv9YjWCxUQqn+z6e1RTFFCrqsnMWSSnmn6Qa28JPoUm6SejRiAy9rgm74tcExMBFuVBRpDPN1vbE8Hrp7QJ+nJuBe1WD3A6o2wwdMpow= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Qztl/Yas; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Qztl/Yas" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745015830; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GQmQfMpW8va+UTCEXGmkf3H4xjY6QXJiuqlXROT9njk=; b=Qztl/Yasa1y9xE9NzieJ4zjh43mbEysv3ZPJGEW83wnPz7V6kdWchYcCgaKFV/QhO8hMxg pcVAm0JXoRSa/BTvh1oafg6Rw5Hf7iU+0YdPJWCK6qYMsbhtTv3JiVO7d7jFyQPqQpq7YM dHyHQ0NKQravWFOHqPNu8a4V32/TNx8= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-607-SYG6l-PeNDafTOuSFqMW9Q-1; Fri, 18 Apr 2025 18:37:06 -0400 X-MC-Unique: SYG6l-PeNDafTOuSFqMW9Q-1 X-Mimecast-MFC-AGG-ID: SYG6l-PeNDafTOuSFqMW9Q_1745015825 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 86CB1195608E; Fri, 18 Apr 2025 22:37:05 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.18]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id EE42F1801770; Fri, 18 Apr 2025 22:37:01 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, shivankg@amd.com, vishal.moola@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH v2 1/5] mm/vmalloc.c: change purge_ndoes as local static variable Date: Sat, 19 Apr 2025 06:36:49 +0800 Message-ID: <20250418223653.243436-2-bhe@redhat.com> In-Reply-To: <20250418223653.243436-1-bhe@redhat.com> References: <20250418223653.243436-1-bhe@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Static variable 'purge_ndoes' is defined in global scope, while it's only used in function __purge_vmap_area_lazy(). It mainly serves to avoid memory allocation repeatedly, especially when NR_CPUS is big. While a local static variable can also satisfy the demand, and can improve code readibility. Hence move its definition into __purge_vmap_area_lazy(). Signed-off-by: Baoquan He Reviewed-by: Uladzislau Rezki (Sony) Reviewed-by: Vishal Moola (Oracle) Reviewed-by: Shivank Garg --- mm/vmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 3ed720a787ec..38d8d8d60985 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2111,7 +2111,6 @@ static DEFINE_MUTEX(vmap_purge_lock); =20 /* for per-CPU blocks */ static void purge_fragmented_blocks_allcpus(void); -static cpumask_t purge_nodes; =20 static void reclaim_list_global(struct list_head *head) @@ -2244,6 +2243,7 @@ static bool __purge_vmap_area_lazy(unsigned long star= t, unsigned long end, { unsigned long nr_purged_areas =3D 0; unsigned int nr_purge_helpers; + static cpumask_t purge_nodes; unsigned int nr_purge_nodes; struct vmap_node *vn; int i; --=20 2.41.0 From nobody Sun Dec 14 12:17:05 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76C0824BBFD for ; Fri, 18 Apr 2025 22:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015846; cv=none; b=NSv66nUUVoOIDXPoEYGihDkQac0s7Vg/O8IsVlt3FzNk+qwS8X/wtW3pNCFfvi5B522U2l5LLhRYn29vfwKt0tZVa3hCrERzZeKkEDXaX/j2eyjfZ8cyzRKoA/49x/efvwfEPE2z0urnWwxyL85LFouvbdY8i3Tu61q1WogHeJg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015846; c=relaxed/simple; bh=kYNdoL242HSxJlPnms0oIlaA/F7Fg6AKx+Jxeqe9C/A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=KGk7o6CXEoGmYemGuqb8w2CRch992xcmgysLJDEoDW8OQBVmOzO1QWw15xVezO29MDOLbxLdTr5m0b4+yFU+uwv+6GlHM5S6ovW0D0g3lwNlQwpIQAj/+pYKuHpih6mxaJIBPhA35+wiG41Y888+8seuaVcI/iOOkC2BBWXAD0I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Cb/uHYeq; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Cb/uHYeq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745015843; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N03GjPg+BmwvkdI230y4vGT1CcitzFu3NJniCzF+Rsw=; b=Cb/uHYequ35DoT/BBHLWwRRREH9dUsLNeXxdI+/It7dxqYB6dlHJcwzI4JSpFz+MW50qtY UVQ05u+ND5+tQlbUHjJ1mzE4LYZNNWpK4l0d5SLqONbN8btY380Psq4Is3FH43EfiiCi18 QC0v4ZB0NkXUXW8yvnL7d4OpXUArOs8= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-593-SjUqEOZHO7ShtuCuGzKiXA-1; Fri, 18 Apr 2025 18:37:18 -0400 X-MC-Unique: SjUqEOZHO7ShtuCuGzKiXA-1 X-Mimecast-MFC-AGG-ID: SjUqEOZHO7ShtuCuGzKiXA_1745015831 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4148F180034A; Fri, 18 Apr 2025 22:37:11 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.18]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DF064180177F; Fri, 18 Apr 2025 22:37:05 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, shivankg@amd.com, vishal.moola@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH v2 2/5] mm/vmalloc.c: find the vmap of vmap_nodes in reverse order Date: Sat, 19 Apr 2025 06:36:50 +0800 Message-ID: <20250418223653.243436-3-bhe@redhat.com> In-Reply-To: <20250418223653.243436-1-bhe@redhat.com> References: <20250418223653.243436-1-bhe@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" When finding VA in vn->busy, if VA spans several zones and the passed addr is not the same as va->va_start, we should scan the vn in reverse odrdr because the starting address of VA must be smaller than the passed addr if it really resides in the VA. E.g on a system nr_vmap_nodes=3D100, <----va----> -|-----|-----|-----|-----|-----|-----|-----|-----|-----|- ... n-1 n n+1 n+2 ... 100 0 1 VA resides in node 'n' whereas it spans 'n', 'n+1' and 'n+2'. If passed addr is within 'n+2', we should try nodes backwards on 'n+1' and 'n', then succeed very soon. Meanwhile we still need loop around because VA could spans node from 'n' to node 100, node 0, node 1. Anyway, changing to find in reverse order can improve efficiency on many CPUs system. Signed-off-by: Baoquan He Reviewed-by: Uladzislau Rezki (Sony) Reviewed-by: Shivank Garg --- mm/vmalloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 38d8d8d60985..76ab4d3ce616 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2421,7 +2421,7 @@ struct vmap_area *find_vmap_area(unsigned long addr) =20 if (va) return va; - } while ((i =3D (i + 1) % nr_vmap_nodes) !=3D j); + } while ((i =3D (i + nr_vmap_nodes - 1) % nr_vmap_nodes) !=3D j); =20 return NULL; } @@ -2447,7 +2447,7 @@ static struct vmap_area *find_unlink_vmap_area(unsign= ed long addr) =20 if (va) return va; - } while ((i =3D (i + 1) % nr_vmap_nodes) !=3D j); + } while ((i =3D (i + nr_vmap_nodes - 1) % nr_vmap_nodes) !=3D j); =20 return NULL; } --=20 2.41.0 From nobody Sun Dec 14 12:17:05 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45ECF1E49F for ; Fri, 18 Apr 2025 22:37:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015845; cv=none; b=GdKJZMcBWk5EmtImyjdvYm3hC85TG16lBnRDZNSaezviQ1wQSWGcqRF3BW+JIBZ9JMR2f0wfNsptiLp9Zc74j8qkRNpe/PUGfqZDEBhlPOVUMnjJZUZOpF60w8x1iwUvRvblN6BxYoNf2kplAzrFw4URdRVjIezRfOceYDb6bCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015845; c=relaxed/simple; bh=UBlASDVwjb3xq+74DdLIUbYJqk15ElEF6MeTXvgIAtU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=ZcT44JlmURp1OzeekQWdkb5c8DXiKsT4bKo3QT29m5qJfSU6RXgQvpl/1Soro7osCSMRui0D2EmKw32W9JomTZLelRIjvT20GkjzABZw9zZjY5sss0WsNJ22nBZfeEwbGU7yogbhcOwMicri012dnJJO2tvnT4RVIuy0+1IyUFk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JwFa5vH2; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JwFa5vH2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745015842; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5CqaNyVqh6Pco3lRKN4a8MRDCkCUASVHhS+U1Kf4kAE=; b=JwFa5vH2SuJAAACjT4KwdEO9imnqdonJUTIFS1j+RRIQOsQHnGLBWPxbMh57h9otDiSDrn G0kGGr+30X5VVSM9BIHCt4+iZJxMmFXWAqoYHYHnRu+vvuCLfBa/Ncxwy1b3fJzRFRbMd5 DTSko060e73Am+NaYfiZpPQ7V5tgMBA= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-447-SpM8dBtoNYK9z96TxEmhJw-1; Fri, 18 Apr 2025 18:37:17 -0400 X-MC-Unique: SpM8dBtoNYK9z96TxEmhJw-1 X-Mimecast-MFC-AGG-ID: SpM8dBtoNYK9z96TxEmhJw_1745015835 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 998D31800263; Fri, 18 Apr 2025 22:37:15 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.18]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id EF78A1801770; Fri, 18 Apr 2025 22:37:11 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, shivankg@amd.com, vishal.moola@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH v2 3/5] mm/vmalloc.c: optimize code in decay_va_pool_node() a little bit Date: Sat, 19 Apr 2025 06:36:51 +0800 Message-ID: <20250418223653.243436-4-bhe@redhat.com> In-Reply-To: <20250418223653.243436-1-bhe@redhat.com> References: <20250418223653.243436-1-bhe@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" When purge lazily freed vmap areas, VA stored in vn->pool[] will also be taken away into free vmap tree partially or completely accordingly, that is done in decay_va_pool_node(). When doing that, for each pool of node, the whole list is detached from the pool for handling. At this time, that pool is empty. It's not necessary to update the pool size each time when one VA is removed and addded into free vmap tree. Here change code to update the pool size when attaching the pool back. Signed-off-by: Baoquan He Reviewed-by: Uladzislau Rezki (Sony) --- mm/vmalloc.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 76ab4d3ce616..cd654cc35d2b 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2133,7 +2133,7 @@ decay_va_pool_node(struct vmap_node *vn, bool full_de= cay) LIST_HEAD(decay_list); struct rb_root decay_root =3D RB_ROOT; struct vmap_area *va, *nva; - unsigned long n_decay; + unsigned long n_decay, pool_len; int i; =20 for (i =3D 0; i < MAX_VA_SIZE_PAGES; i++) { @@ -2147,22 +2147,20 @@ decay_va_pool_node(struct vmap_node *vn, bool full_= decay) list_replace_init(&vn->pool[i].head, &tmp_list); spin_unlock(&vn->pool_lock); =20 - if (full_decay) - WRITE_ONCE(vn->pool[i].len, 0); + pool_len =3D n_decay =3D vn->pool[i].len; + WRITE_ONCE(vn->pool[i].len, 0); =20 /* Decay a pool by ~25% out of left objects. */ - n_decay =3D vn->pool[i].len >> 2; + if (!full_decay) + n_decay >>=3D 2; + pool_len -=3D n_decay; =20 list_for_each_entry_safe(va, nva, &tmp_list, list) { + if (!n_decay--) + break; + list_del_init(&va->list); merge_or_add_vmap_area(va, &decay_root, &decay_list); - - if (!full_decay) { - WRITE_ONCE(vn->pool[i].len, vn->pool[i].len - 1); - - if (!--n_decay) - break; - } } =20 /* @@ -2171,9 +2169,10 @@ decay_va_pool_node(struct vmap_node *vn, bool full_d= ecay) * can populate the pool therefore a simple list replace * operation takes place here. */ - if (!full_decay && !list_empty(&tmp_list)) { + if (!list_empty(&tmp_list)) { spin_lock(&vn->pool_lock); list_replace_init(&tmp_list, &vn->pool[i].head); + WRITE_ONCE(vn->pool[i].len, pool_len); spin_unlock(&vn->pool_lock); } } --=20 2.41.0 From nobody Sun Dec 14 12:17:05 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E789253F1B for ; Fri, 18 Apr 2025 22:37:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015849; cv=none; b=Hv1ro3+zGpxbxFckoKA0Uj3uNaHQShdAcacRPVrp6h32/uXzM03jzKQ3BXNTRZFdFpd4P136ECbNCsgwam237vt/f2JpxvI2Ew0iJo0p+289c8az9hCcoU3AMA0QF18H5lY88rhPPIPSjoU7E1fKFj1XFsAhgHtLZn7TcDsjiQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015849; c=relaxed/simple; bh=8BwZsnVdR8miAoiDxdE54co2xvNhNwAiNXUjNPp92dA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=AlRtNXszHbjUlBMt0GOESG+VEreEj4aa1QexO441XYvL6VvrBUJIjBIFJsavNghAeyUPoniXEy6k43GsuVJ5y5vK627I/ouhC/dE0TlwCsnQ5VwmkO0c4wYYszXW/BpInyqqT2xigqflJSIRg2nS97hW8IAn6uFFqFR52CcTN/M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Kq2ZHjCy; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Kq2ZHjCy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745015846; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZGf05WSXfY+l3YCUw1WKme5A0IS/vcfpVKsXA2Mq+zc=; b=Kq2ZHjCyUKSsTbbEzDVpYyTZfTQlbMLMEM66IzDDHsihxjE4NNtlV+/lZMMIyX25V4CuKH ONfU3zFdnTXiC9ztIidfVI4VlmRf3zOM7o9pIpHgvrNS8CWGugqzV68KnMpAJ7jiUEMQNj EvWyvH/eO5C86sLYDByFoAdvtPWuQXY= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-437-Hyg7DzC2MiKoUIJ60zMYKQ-1; Fri, 18 Apr 2025 18:37:23 -0400 X-MC-Unique: Hyg7DzC2MiKoUIJ60zMYKQ-1 X-Mimecast-MFC-AGG-ID: Hyg7DzC2MiKoUIJ60zMYKQ_1745015842 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EA72D1956086; Fri, 18 Apr 2025 22:37:21 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.18]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CE2E81801770; Fri, 18 Apr 2025 22:37:16 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, shivankg@amd.com, vishal.moola@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH v2 4/5] mm/vmalloc: optimize function vm_unmap_aliases() Date: Sat, 19 Apr 2025 06:36:52 +0800 Message-ID: <20250418223653.243436-5-bhe@redhat.com> In-Reply-To: <20250418223653.243436-1-bhe@redhat.com> References: <20250418223653.243436-1-bhe@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Remove unneeded local variables and replace them with values. Signed-off-by: Baoquan He Reviewed-by: Uladzislau Rezki (Sony) Reviewed-by: Vishal Moola (Oracle) Reviewed-by: Shivank Garg --- mm/vmalloc.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index cd654cc35d2b..39e043ba969b 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2915,10 +2915,7 @@ static void _vm_unmap_aliases(unsigned long start, u= nsigned long end, int flush) */ void vm_unmap_aliases(void) { - unsigned long start =3D ULONG_MAX, end =3D 0; - int flush =3D 0; - - _vm_unmap_aliases(start, end, flush); + _vm_unmap_aliases(ULONG_MAX, 0, 0); } EXPORT_SYMBOL_GPL(vm_unmap_aliases); =20 --=20 2.41.0 From nobody Sun Dec 14 12:17:05 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DD5E25334F for ; Fri, 18 Apr 2025 22:37:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015854; cv=none; b=WzgTUflZMgx0RgVARiC1LIfGYFMuAwOft3gAkDgnPz3Lc450T6ho0CZwUICgnFcGG3WNLjvMTmnR0yLFVNLoFUiQeIoG90qXdAoLsKVH7eo68J39vRTIakDrXpRzDM61bxYM1PZi2moy5ZB6068QGvxEDyMsiqOVO5Pt2J6fKbw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745015854; c=relaxed/simple; bh=+2yRZixQSCiIQZetZD/H/onwj/GI2xM1iSUIHFkUhr8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=c4+Rl1QVFDXnbrTvY1jrrQ5vWA+xTrILBRt1mg9Yj4naYHhO4zQad8WlHKCQCj+xiYMmuaDzZmEsSryqp6cXE8y+N+YFgp5eb4CppYIDBeDVndskhfSlglkfF3oOnBMqEpLSeQfO0etyRrqVe3I7Fj4FO+RjAbIY3bZxdtwvstQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=idXtt3YN; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="idXtt3YN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745015851; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pgvL41QdbZrb/DItLyL8hX9WAHY/XF9TJNGkmiBOQ9k=; b=idXtt3YNWzbt0MEkvh/eFxmVszWWJlzQ4CIknBB2/ZG4xDbcmP+dDfchVkwFK6BOM6nXs/ QRpEJjCb0v7ABQW3E0A9vxyCzaZ0bItSQKqTgnrr+XBmncMchtuU1Y0YuihTX3p2vxQtc3 QYieFhu5EghKTJziyhXE0VhwOUYdTOo= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-41-eG8EADjgPq2JGZadomQzNg-1; Fri, 18 Apr 2025 18:37:27 -0400 X-MC-Unique: eG8EADjgPq2JGZadomQzNg-1 X-Mimecast-MFC-AGG-ID: eG8EADjgPq2JGZadomQzNg_1745015846 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 49E7119560A6; Fri, 18 Apr 2025 22:37:26 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.18]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9C4D81801770; Fri, 18 Apr 2025 22:37:22 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, shivankg@amd.com, vishal.moola@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH v2 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area() Date: Sat, 19 Apr 2025 06:36:53 +0800 Message-ID: <20250418223653.243436-6-bhe@redhat.com> In-Reply-To: <20250418223653.243436-1-bhe@redhat.com> References: <20250418223653.243436-1-bhe@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" In codes of alloc_vmap_area(), it returns the upper bound 'vend' to indicate if the allocation is successful or failed. That is not very clear. Here change to return explicit error values and check them to judge if allocation is successful. Signed-off-by: Baoquan He Reviewed-by: Uladzislau Rezki (Sony) --- mm/vmalloc.c | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 39e043ba969b..0251402ca5b9 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1698,7 +1698,7 @@ va_clip(struct rb_root *root, struct list_head *head, */ lva =3D kmem_cache_alloc(vmap_area_cachep, GFP_NOWAIT); if (!lva) - return -1; + return -ENOMEM; } =20 /* @@ -1712,7 +1712,7 @@ va_clip(struct rb_root *root, struct list_head *head, */ va->va_start =3D nva_start_addr + size; } else { - return -1; + return -EINVAL; } =20 if (type !=3D FL_FIT_TYPE) { @@ -1741,19 +1741,19 @@ va_alloc(struct vmap_area *va, =20 /* Check the "vend" restriction. */ if (nva_start_addr + size > vend) - return vend; + return -ERANGE; =20 /* Update the free vmap_area. */ ret =3D va_clip(root, head, va, nva_start_addr, size); if (WARN_ON_ONCE(ret)) - return vend; + return ret; =20 return nva_start_addr; } =20 /* * Returns a start address of the newly allocated area, if success. - * Otherwise a vend is returned that indicates failure. + * Otherwise an error value is returned that indicates failure. */ static __always_inline unsigned long __alloc_vmap_area(struct rb_root *root, struct list_head *head, @@ -1778,14 +1778,13 @@ __alloc_vmap_area(struct rb_root *root, struct list= _head *head, =20 va =3D find_vmap_lowest_match(root, size, align, vstart, adjust_search_si= ze); if (unlikely(!va)) - return vend; + return -ENOENT; =20 nva_start_addr =3D va_alloc(va, root, head, size, align, vstart, vend); - if (nva_start_addr =3D=3D vend) - return vend; =20 #if DEBUG_AUGMENT_LOWEST_MATCH_CHECK - find_vmap_lowest_match_check(root, head, size, align); + if (!IS_ERR_VALUE(nva_start_addr)) + find_vmap_lowest_match_check(root, head, size, align); #endif =20 return nva_start_addr; @@ -1915,7 +1914,7 @@ node_alloc(unsigned long size, unsigned long align, struct vmap_area *va; =20 *vn_id =3D 0; - *addr =3D vend; + *addr =3D -EINVAL; =20 /* * Fallback to a global heap if not vmalloc or there @@ -1995,20 +1994,20 @@ static struct vmap_area *alloc_vmap_area(unsigned l= ong size, } =20 retry: - if (addr =3D=3D vend) { + if (IS_ERR_VALUE(addr)) { preload_this_cpu_lock(&free_vmap_area_lock, gfp_mask, node); addr =3D __alloc_vmap_area(&free_vmap_area_root, &free_vmap_area_list, size, align, vstart, vend); spin_unlock(&free_vmap_area_lock); } =20 - trace_alloc_vmap_area(addr, size, align, vstart, vend, addr =3D=3D vend); + trace_alloc_vmap_area(addr, size, align, vstart, vend, IS_ERR_VALUE(addr)= ); =20 /* - * If an allocation fails, the "vend" address is + * If an allocation fails, the error value is * returned. Therefore trigger the overflow path. */ - if (unlikely(addr =3D=3D vend)) + if (IS_ERR_VALUE(addr)) goto overflow; =20 va->va_start =3D addr; --=20 2.41.0