On 02/06/2015 08:32 PM, Peter Zijlstra wrote: > On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote: >> Certainly looks much simpler, but it adds quite a bit of data to the >> omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration. >> >> ls -al vmlinux >> >> w/o any the lockdep warning fixes: >> 110109168 >> >> With my series applied: >> 110112031 (base + 2863) >> >> With setting individual lockdep class: >> 110114275 (base + 5107) >> >> I certainly like the lockdep_set_class() way since it is cleaner, but it adds >> almost double amount of bytes to the kernel. > > 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. Thanks, Péter -- 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
