On Fri, Jun 10, 2016 at 11:47:48AM -0700, Florian Fainelli wrote:
> On 06/10/2016 05:00 AM, Andrew Lunn wrote:
> >> @@ -148,6 +155,9 @@ struct bcm_sf2_priv {
> >> struct device_node *master_mii_dn;
> >> struct mii_bus *slave_mii_bus;
> >> struct mii_bus *master_mii_bus;
> >> +
> >> + /* Cache of programmed VLANs */
> >> + struct bcm_sf2_vlan vlans[VLAN_N_VID];
> >
> > Hi Florian
> >
> > This is a 16Kbyte array. So i assume the whole priv structure needs 5
> > pages. Have you had any trouble allocating this much memory,
> > particularly once it has been used for a while and fragmented?
>
> Well, since this is using the old binding, we can't unload the driver,
> it's built into the kernel, so initializes early enough we have got
> plenty of memory.
Don't you want to use the new binding at some point?
> > I just wondered if it might be better to use vmalloc() for the
> > vlans.
>
> That's a very good point, I can't really see a drawback to doing this,
> will submit a patch moving this to a dynamic allocation.
>
> Another possible approach would have been to allocate the vlan structure
> upong port_vlan_prepare() though that would typically result in more
> fragmentation over time once se start using more VLANs.
It is a trade off, code complexity vs saved memory. I don't think such
a table is too bad, assuming your not trying to run the whole system
in 32Mbyes of RAM.
Andrew