From nobody Fri Dec 19 16:02:35 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 62F3B4A1A for ; Tue, 15 Apr 2025 02:40:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684811; cv=none; b=Fnwi9WvoB0LUEUdihrA+NwAxGt7J6zEQ31CCE7PFcpdwADq92eDnZ0nbBuBtAokLKFx2r1xueTF15V2xXFYmOetGc9qQ72nCM1wda/vwJiszVXUYpADyS+lbO8BkYrLf4oaeL6f71ZazKNsEtKucjscjlQwtpwSWh5yYEcLP37I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684811; c=relaxed/simple; bh=eOfjC0BHia++C3VKqQifXQ3HjFpe1y5DuEP753mXmxs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=He1IkV5soOx4cP2rFtOiiMD+ze9Yizqpcik2zX9qoUtGKyJ4nO2rms3W5j/OGtmKYynFw5bk6q+pcV8y9BJv68VeB4Pf1qdEJK1gURr8Ses6s9UAAz3HSGC7SXc85/1L2icj54NPyzmW0Vf8P8fyXZ3AlZJdPO8stqQnDuMIuas= 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=EMV2dRhj; arc=none smtp.client-ip=170.10.133.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="EMV2dRhj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744684808; 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=abWHD7HGRJypdiZsKpqwwuf0n8E4BGzV2LjQF8XVdqk=; b=EMV2dRhjUXMF6L98crcFnOP0L2G1zTq2z5F0Cg1PfvNrfIscFZTYbL25vwomkhws2N0e/J oiddVPCqFKA0Isy4pGmYmugHNTxjefRYwEZqhq4lznkHtq5Y48MVyKXwOsQcyrmXTUykaq aMzVEw0y0X5h/0kUwGHf12WX5ipsQ0s= 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-390-O-XFv-pgMZmdIzugaGbJaA-1; Mon, 14 Apr 2025 22:40:04 -0400 X-MC-Unique: O-XFv-pgMZmdIzugaGbJaA-1 X-Mimecast-MFC-AGG-ID: O-XFv-pgMZmdIzugaGbJaA_1744684803 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 5691219560B0; Tue, 15 Apr 2025 02:40:03 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.37]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 85319180B487; Tue, 15 Apr 2025 02:40:00 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH 1/5] mm/vmalloc.c: change purge_ndoes as local static variable Date: Tue, 15 Apr 2025 10:39:48 +0800 Message-ID: <20250415023952.27850-2-bhe@redhat.com> In-Reply-To: <20250415023952.27850-1-bhe@redhat.com> References: <20250415023952.27850-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.93 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: Shivank Garg Reviewed-by: Uladzislau Rezki (Sony) Reviewed-by: Vishal Moola (Oracle) Tested-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 6ee7fc2ec986..aca1905d3397 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2128,7 +2128,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) @@ -2261,6 +2260,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 Fri Dec 19 16:02:35 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 A3F33207643 for ; Tue, 15 Apr 2025 02:40:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684815; cv=none; b=dtxkXJCkZ2k4ZfgWiwm5nz4Yzwysxrrt6cIcnCjbK6LkemCNesgC53GLNTTuqBqd22t+dDZfgfY+aDKRqBJejCit9it+OqWKzC78VE+W2OsbA1Kb5TiWhw3ACXbFMh4lqTFGi489hI51/ow88S2AndorYnEHMFSykCTbZ+V7Mjc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684815; c=relaxed/simple; bh=JQn2L+MnvFH/8v2FS6oR4Y87JX0h1LGPvmjEi3ni2Vg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=hMA920OwQeFVUUvLkP98df5SRo/XDrmaIfw5sGGtsG3VbUn4xX6lhhUvqD2f+WCUN14kZ0DRVxCdwLNgnhfWUlUhRe6OIDxRrqreiY4Hk07Z/zsK3ZEG9h2R80z/by8MG63LfQRyy7CM5sB0iv6AdL39XhYR6E33tlRPE73r0/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=f5uAYxqJ; arc=none smtp.client-ip=170.10.133.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="f5uAYxqJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744684812; 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=xaA7QUljbHhdtc6rrmuJ0uIfqNU2ZokdPYOHiaV6YkU=; b=f5uAYxqJU7Xoec6r3hIS/Li3Upba5EID8xrpNCsLrcrWiZdPTFHhBdil+ASFukKX3ordsd K/H191UqbOjVVrUTE2PSPR2c4YKSJdhowZFalh5Md5WsKq36LG4sRK//YTR+PXvYD0XbhG 192C+ockxArZCeA2qYNVcxqrX2e9vjs= Received: from mx-prod-mc-03.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-614-pzPVa-zbM5GJ1NFvad52Ig-1; Mon, 14 Apr 2025 22:40:08 -0400 X-MC-Unique: pzPVa-zbM5GJ1NFvad52Ig-1 X-Mimecast-MFC-AGG-ID: pzPVa-zbM5GJ1NFvad52Ig_1744684807 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8D3CB19560B6; Tue, 15 Apr 2025 02:40:07 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.37]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id AB498180AF7C; Tue, 15 Apr 2025 02:40:03 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH 2/5] mm/vmalloc.c: find the vmap of vmap_nodes in reverse order Date: Tue, 15 Apr 2025 10:39:49 +0800 Message-ID: <20250415023952.27850-3-bhe@redhat.com> In-Reply-To: <20250415023952.27850-1-bhe@redhat.com> References: <20250415023952.27850-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.93 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: Shivank Garg Reviewed-by: Uladzislau Rezki (Sony) Tested-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 aca1905d3397..488d69b56765 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2436,7 +2436,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; } @@ -2462,7 +2462,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 Fri Dec 19 16:02:35 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 DA511211A3C for ; Tue, 15 Apr 2025 02:40:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684819; cv=none; b=di980dCDMLwWAZohu9sglLupEczKskTMyXKhPsxm4gjf9VBu5nFr4J9HvhsQat1phj6ZJ7XJGtGiEF7r7ycO5weMxVGm6Gd5cWcLaj6zp2b27GyW0NJHljzOVpZxw7bzlz5qRWfd+4vNbHPoeve7b1KWou3DZASygWOrXK5YWHg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684819; c=relaxed/simple; bh=QfShxFv9ltw6jMWiZ17nc3fNMjYd8cKjfMqKbqQfLUY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=lV1MMFg9xGa8Z9q1OuXV8WII43C3DlrV90Y9JEIe+FZpeJNOaDLsYrsv+0GUqPqI1tfTW57spK+CFdM8nd2BdO5Fmb2pCotSGnX0b8xUs+MMdt3ecaJUUTmUAAvZOaF4JWyGr1whU3voIfS6bxKP7CRW3JF64DM4QxZ0qLBkUUs= 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=g2pAhOLz; arc=none smtp.client-ip=170.10.133.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="g2pAhOLz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744684816; 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=aHl/Z9s4nujmOJmJ3+sr23NFZCZ38U3X11XyM8VuKPk=; b=g2pAhOLzA1h6i64ebfLAUdZjScB3BmpYcvDMxk2h7ZH356BeCRBYqC17YFTvQnCuh+FFEk dbfq0Hp81t6df4yzMdpSHRoOWK4F6Iz6O9mrzoiTT9dLtVKT29NDLhCPpVtwmHTzaooD+Z xSPAfqS6jvBF9zAi8fTr2TjR1ozKBo8= Received: from mx-prod-mc-04.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-618-Y0MOwrwTNliPZTXflYU4iw-1; Mon, 14 Apr 2025 22:40:12 -0400 X-MC-Unique: Y0MOwrwTNliPZTXflYU4iw-1 X-Mimecast-MFC-AGG-ID: Y0MOwrwTNliPZTXflYU4iw_1744684811 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4425419560BB; Tue, 15 Apr 2025 02:40:11 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.37]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4D45E180AF7C; Tue, 15 Apr 2025 02:40:07 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH 3/5] mm/vmalloc.c: optimize code in decay_va_pool_node() a little bit Date: Tue, 15 Apr 2025 10:39:50 +0800 Message-ID: <20250415023952.27850-4-bhe@redhat.com> In-Reply-To: <20250415023952.27850-1-bhe@redhat.com> References: <20250415023952.27850-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.93 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: Shivank Garg Tested-by: Shivank Garg --- mm/vmalloc.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 488d69b56765..bf735c890878 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2150,7 +2150,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, len; int i; =20 for (i =3D 0; i < MAX_VA_SIZE_PAGES; i++) { @@ -2164,22 +2164,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); + 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; + 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; - } + n_decay--; } =20 /* @@ -2188,9 +2186,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); + vn->pool[i].len =3D len; spin_unlock(&vn->pool_lock); } } --=20 2.41.0 From nobody Fri Dec 19 16:02:35 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 CF62F20D519 for ; Tue, 15 Apr 2025 02:40:23 +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=1744684825; cv=none; b=T82mqmuqNGvDdWAxMQrpeMn3gkgn7IXMEg+VgW2OScflJeNh39/5n3bYP4K2H93+JYh+oDIEEfy+UPZfTsXx1mWMObRSqcQrqlpEvyNH1XHlwZYwxE2JuIoV5o5FBGRLtOEVfyYyBFxTKw38PBahkp+45z/qc3LjDL21q5iQKIU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684825; c=relaxed/simple; bh=tPiYfcRNaN/g+ao5eba1tssr535XVPsQIPQa3IrsRyk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=Z9NtzqeyAHLp8/8iAAq3qWmCn3dpsGfQQquoYeGjl0AF+tnfDZoa+KV8T8+4BkrEAbvmjNSKmgPflmZaAkISs5nkxiB2pZ4aB8wGdz/xHArPH84ezhF/UUpyith3u+sQvp5Ym9I5jEbSYf0wg28LgmmzsRAlW/fOR8zeOT6Fnm0= 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=BGebudI1; 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="BGebudI1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744684822; 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=Tuu/lyEGrQ5huyvs2A1U9HCIOm5LTsOq/3jwVMuJmBY=; b=BGebudI1XuN407VCTvJ6/XAnNiLzJNH0muoZnzl1nWXgok/dgRxsCNSHK2EJhz1kzTtRxH GmKmAkw5L16KSvoXYkrMwOrq2S/JT+paKbTB+BGP4ARFQbrzPUfpaYqNJ4eV7RNXlEoLV2 4vOhZOfI1lHbsElZazQbNOjNggO4f4M= 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-301-a8lRE-JPN2Cate1uTDxBig-1; Mon, 14 Apr 2025 22:40:16 -0400 X-MC-Unique: a8lRE-JPN2Cate1uTDxBig-1 X-Mimecast-MFC-AGG-ID: a8lRE-JPN2Cate1uTDxBig_1744684814 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 AC72319560B7; Tue, 15 Apr 2025 02:40:14 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.37]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 03A6E180AF7C; Tue, 15 Apr 2025 02:40:11 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH 4/5] mm/vmalloc: optimize function vm_unmap_aliases() Date: Tue, 15 Apr 2025 10:39:51 +0800 Message-ID: <20250415023952.27850-5-bhe@redhat.com> In-Reply-To: <20250415023952.27850-1-bhe@redhat.com> References: <20250415023952.27850-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.93 Content-Type: text/plain; charset="utf-8" Remove unneeded local variables and replace them with values. Signed-off-by: Baoquan He Reviewed-by: Shivank Garg Reviewed-by: Uladzislau Rezki (Sony) Reviewed-by: Vishal Moola (Oracle) Tested-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 bf735c890878..3f38a232663b 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2930,10 +2930,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 Fri Dec 19 16:02:35 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 570C8214A88 for ; Tue, 15 Apr 2025 02:40:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684828; cv=none; b=AkCFfIb7uK15JvY4WElyWRD4EhF9u8s3Z77hoCmWKy1e2vBZzZT5QV1g9qpQsP8lWxOwn3prb2XT28nTDXBODytNs0DU0TF+2Nii0Unvq/lU6TlSEuAdKfFUjkwBf21q4vjZaD1H54MKyeYme61WRjLLwkEGoRXridEg37Q0HKI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744684828; c=relaxed/simple; bh=kRf/FD/ltZZPe2Hd0lOVAHpWrJdUO97fnrcz2lxv6/o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-type; b=IIYQta3FYz1r89Vbxymm/uB0cKmSPNvnSnxkQrwkci4xT1Qvrbem0AKh6KeoBNT8MFD497UgGLcgTGeQxXQuM9jpU25NA/0nUED4PLwBFJvwAJZD+6xE2wxThdJFcF3ZRUUMMb1QSPS1hXDkfjixkgNhmscjQLlinjId3+WjpgY= 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=Zr59qvX8; arc=none smtp.client-ip=170.10.133.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="Zr59qvX8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744684825; 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=BiTd6gkzO3xlq1GH+oaUM8JNSi1IBXTiwuoOQeUrUeY=; b=Zr59qvX8NIKXbhpU1E4CTs3JBRXVbN0dQf4Ssh3ALIakcExw397CgBtgiFbolJCh1X6vu0 aWjVYeicwkyqtsffnh5hod6NCEc0kYuidtq2Bshzqs8MoV6GH1L0xH3PSqTyeaDXscoWKM fLrAK/OMJkgyEWclZ2DxxrxJAhlWaxg= 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-54-QAQo5PuTOp6H9Q-QuYLKpw-1; Mon, 14 Apr 2025 22:40:19 -0400 X-MC-Unique: QAQo5PuTOp6H9Q-QuYLKpw-1 X-Mimecast-MFC-AGG-ID: QAQo5PuTOp6H9Q-QuYLKpw_1744684818 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 1AEAC19560B3; Tue, 15 Apr 2025 02:40:18 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (unknown [10.72.112.37]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6F3B8180AF7C; Tue, 15 Apr 2025 02:40:15 +0000 (UTC) From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, urezki@gmail.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [PATCH 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area() Date: Tue, 15 Apr 2025 10:39:52 +0800 Message-ID: <20250415023952.27850-6-bhe@redhat.com> In-Reply-To: <20250415023952.27850-1-bhe@redhat.com> References: <20250415023952.27850-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.93 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. IS_ERR_VALUE already uses unlikely() internally Signed-off-by: Baoquan He Reviewed-by: Shivank Garg Tested-by: Shivank Garg --- mm/vmalloc.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 3f38a232663b..5b21cd09b2b4 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1715,7 +1715,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 /* @@ -1729,7 +1729,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) { @@ -1758,19 +1758,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; + if (ret) + 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, @@ -1795,14 +1795,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; @@ -1932,7 +1931,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 @@ -2012,20 +2011,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; @@ -4753,9 +4752,10 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned = long *offsets, =20 ret =3D va_clip(&free_vmap_area_root, &free_vmap_area_list, va, start, size); - if (WARN_ON_ONCE(unlikely(ret))) - /* It is a BUG(), but trigger recovery instead. */ + if ((unlikely(ret))) { + WARN_ONCE(1, "%s error: errno (%d)\n", __func__, ret); goto recovery; + } =20 /* Allocated area. */ va =3D vas[area]; --=20 2.41.0