* Paul Walmsley <paul@xxxxxxxxx> [150209 08:04]:
> On Mon, 9 Feb 2015, Peter Ujfalusi wrote:
>
> > On 02/06/2015 09:26 PM, Peter Ujfalusi wrote:
> > >> Yeah, I've never really bothered with data too much, its a debug
> > >> feature. So lock_class_key is 8 bytes, and strictly speaking you could
> > >> union them over other fields, all we really need is unique addresses, we
> > >> don't actually use the storage.
> > >
> > > True. our omap2plus defconfig does not have LOCKDEP enabled so it should not
> > > add anything to the data when running default kernel.
> > > I'll test the lockdep_set_class() method you suggested on Monday (not
> > > tomorrow), but still as first thing.
> > > If it is working as expected I'll send a patch with you as author.
> >
> > With omap2plus_defconfig my build produces (vmlinux size):
> > Base: 99905522
> > with my series: 99908385 (base + 2863)
> > with Peter Zijlstra's patch: 99910625 (base + 5103)
> >
> > The reason for this is that we will only have
> > struct lock_class_key { };
> > in case of !CONFIG_LOCKDEP. On ARM however CONFIG_LOCKDEP is enabled by
> > default, while the CONFIG_DEBUG_LOCKDEP is disabled.
> >
> > So it does add more data to our default omap2plus config.
> >
> > Tony: do you have preference on the way we fix this issue?
> >
> > As I recall there is a plan to remove the hwmod static database and move it or
> > generate it from DT? Not sure when and how this will be done, but will it
> > affect the lockdep_set_class() way?
>
> Well I guess we could see what Tony says, but you do realize that the
> difference in sizes that you posted above is about .003% of the total
> binary size, right?
>
> If there's one thing we can say about the last few years of ARM kernel
> development, it's that those kind of size increases are utterly dwarfed by
> other changes in the kernel. So I'd say, post a patch based on PeterZ's
> fix and be done with it...
Well the thing to consider here is what Peter U is saying about
having struct omap_hwmod allocated based on the data from .dts
files. If the fix makes the dynamic allocation harder to do later on,
we should probably avoid it. If it's relatively easy to do later on,
then I don't have a problem with it.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
