linux-kernel - Re: [PATCH net-next 3/8] net: ethernet: mtk_eth_soc: move MAX_DEVS in mtk_soc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZIb6604WRJsevaWN@shell.armlinux.org.uk>
Date:   Mon, 12 Jun 2023 12:00:59 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Daniel Golle <daniel@...rotopia.org>
Cc:     netdev@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        John Crispin <john@...ozen.org>, Felix Fietkau <nbd@....name>,
        Conor Dooley <conor+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sam Shih <Sam.Shih@...iatek.com>
Subject: Re: [PATCH net-next 3/8] net: ethernet: mtk_eth_soc: move MAX_DEVS
 in mtk_soc_data

On Sun, Jun 11, 2023 at 01:35:17AM +0100, Daniel Golle wrote:
> @@ -1106,14 +1105,14 @@ struct mtk_eth {
>  	spinlock_t			tx_irq_lock;
>  	spinlock_t			rx_irq_lock;
>  	struct net_device		dummy_dev;
> -	struct net_device		*netdev[MTK_MAX_DEVS];
> -	struct mtk_mac			*mac[MTK_MAX_DEVS];
> +	struct net_device		**netdev;
> +	struct mtk_mac			**mac;
>  	int				irq[3];
>  	u32				msg_enable;
>  	unsigned long			sysclk;
>  	struct regmap			*ethsys;
>  	struct regmap			*infra;
> -	struct phylink_pcs		*sgmii_pcs[MTK_MAX_DEVS];
> +	struct phylink_pcs		**sgmii_pcs;
>  	struct regmap			*pctl;
>  	bool				hwlro;
>  	refcount_t			dma_refcnt;

Is it really worth the extra allocations?

There's three pointers here per device. Let's talk about modern systems,
so that's 8 bytes each, and if MTK_MAX_DEVS was two, that's 48 bytes in
all. If we expanded the array to allow three, that would be 72 bytes.

If we allocate separately, then we're allocating 16 or 24 bytes three
times depending on whether we want two or three of them.

On arm64, I'm seeing the minimum slab size as 128 bytes, which means
that's the minimum memory allocation. So, allocating three arrays will
be 384 bytes in all, irrespective of whether we want two or three
entries.

That's a waste of about 5x the memory over just expanding the arrays!

If you want to go down the route of dynamically allocating these, it
would make better sense to combine them into a single structure that
itself is an array, and thus requiring only one allocation. That
reduces the wastage to about 56 bytes for three ports or 80 bytes
for two.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!