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...
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
