From nobody Fri Sep 19 11:05:17 2025 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 C5406C4332F for ; Fri, 25 Nov 2022 12:24:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230048AbiKYMY2 (ORCPT ); Fri, 25 Nov 2022 07:24:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229891AbiKYMYS (ORCPT ); Fri, 25 Nov 2022 07:24:18 -0500 Received: from smtp.smtpout.orange.fr (smtp-14.smtpout.orange.fr [80.12.242.14]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D823D4A5BE for ; Fri, 25 Nov 2022 04:24:12 -0800 (PST) Received: from pop-os.home ([86.243.100.34]) by smtp.orange.fr with ESMTPA id yXkRoPBKkY4XVyXkZoE20z; Fri, 25 Nov 2022 13:24:11 +0100 X-ME-Helo: pop-os.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Fri, 25 Nov 2022 13:24:11 +0100 X-ME-IP: 86.243.100.34 From: Christophe JAILLET To: Sunil Goutham , Linu Cherian , Geetha sowjanya , Jerin Jacob , hariprasad , Subbaraya Sundeep , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET , netdev@vger.kernel.org Subject: [PATCH 4/5] octeontx2-af: Fix the size of memory allocated for the 'id_bmap' bitmap Date: Fri, 25 Nov 2022 13:24:00 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" This allocation is really spurious. The size of the bitmap is 'tot_ids' and it is used as such in the driver. So we could expect something like: table->id_bmap =3D devm_kcalloc(rvu->dev, BITS_TO_LONGS(table->tot_ids), sizeof(long), GFP_KERNEL); However, when the bitmap is allocated, we allocate: BITS_TO_LONGS(table->tot_ids) * table->tot_ids ~=3D table->tot_ids / 32 * table->tot_ids ~=3D table->tot_ids^2 / 32 It is proportional to the square of 'table->tot_ids' which seems to potentially be big. Allocate the expected amount of memory, and switch to the bitmap API to have it more straightforward. Signed-off-by: Christophe JAILLET --- This patch is speculative. If I'm right, I'm curious to know if 'able->tot_ids' can really get big (I'm just guessing) , and if yes, how much. --- drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c b/dri= vers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c index 3f94b620ef5a..ae34746341c4 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c @@ -1914,8 +1914,8 @@ int rvu_npc_exact_init(struct rvu *rvu) dev_dbg(rvu->dev, "%s: Allocated bitmap for 32 entry cam\n", __func__); =20 table->tot_ids =3D (table->mem_table.depth * table->mem_table.ways) + tab= le->cam_table.depth; - table->id_bmap =3D devm_kcalloc(rvu->dev, BITS_TO_LONGS(table->tot_ids), - table->tot_ids, GFP_KERNEL); + table->id_bmap =3D devm_bitmap_zalloc(rvu->dev, table->tot_ids, + GFP_KERNEL); =20 if (!table->id_bmap) return -ENOMEM; --=20 2.34.1