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!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ