From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Daniel Golle <daniel@makrotopia.org>,
netdev@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Mark Lee <Mark-MC.Lee@mediatek.com>,
Sean Wang <sean.wang@mediatek.com>,
John Crispin <john@phrozen.org>, Felix Fietkau <nbd@nbd.name>,
Conor Dooley <conor+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Sam Shih <Sam.Shih@mediatek.com>
Subject: Re: [PATCH net-next 3/8] net: ethernet: mtk_eth_soc: move MAX_DEVS in mtk_soc_data
Date: Mon, 12 Jun 2023 23:52:46 +0200 [thread overview]
Message-ID: <ZIeTrjCsyQSiCnsr@lore-desk> (raw)
In-Reply-To: <ZIb6604WRJsevaWN@shell.armlinux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1936 bytes --]
> 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!
ack, I agree. I will fix it.
Regards,
Lorenzo
>
> 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!
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Daniel Golle <daniel@makrotopia.org>,
netdev@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Mark Lee <Mark-MC.Lee@mediatek.com>,
Sean Wang <sean.wang@mediatek.com>,
John Crispin <john@phrozen.org>, Felix Fietkau <nbd@nbd.name>,
Conor Dooley <conor+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Sam Shih <Sam.Shih@mediatek.com>
Subject: Re: [PATCH net-next 3/8] net: ethernet: mtk_eth_soc: move MAX_DEVS in mtk_soc_data
Date: Mon, 12 Jun 2023 23:52:46 +0200 [thread overview]
Message-ID: <ZIeTrjCsyQSiCnsr@lore-desk> (raw)
In-Reply-To: <ZIb6604WRJsevaWN@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
> 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!
ack, I agree. I will fix it.
Regards,
Lorenzo
>
> 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!
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-06-12 22:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-11 0:35 [PATCH net-next 3/8] net: ethernet: mtk_eth_soc: move MAX_DEVS in mtk_soc_data Daniel Golle
2023-06-12 11:00 ` Russell King (Oracle)
2023-06-12 21:52 ` Lorenzo Bianconi [this message]
2023-06-12 21:52 ` Lorenzo Bianconi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZIeTrjCsyQSiCnsr@lore-desk \
--to=lorenzo.bianconi@redhat.com \
--cc=Mark-MC.Lee@mediatek.com \
--cc=Sam.Shih@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=john@phrozen.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=sean.wang@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.