Messages in this thread | | | Subject | Re: [PATCH] mod_devicetable.h: reduce sizeof(struct of_device_id) by 80 bytes | From | Rasmus Villemoes <> | Date | Fri, 26 Apr 2019 13:33:38 +0200 |
| |
On 26/04/2019 13.05, Enrico Weigelt, metux IT consult wrote: > On 25.04.19 22:31, Rasmus Villemoes wrote: > > Hi, > >> A typical kernel image has hundreds of static struct of_device_id >> instances (a lot of which are sentinel all-zeroes), each occupying >> ~200 bytes. Nobody initializes the .compatible member with strings >> anywhere near 128 bytes, so a lot of that memory is simply wasted. > > I just wonder whether it has to be a fixed size array at all, instead > of an const char* pointer. Using a pointer should, IMHO, offer even > more savings while not having the size limit at all.
I did consider that, but file2alias reads the struct directly from the object files, so it would have to be taught to apply relocations and find the string literal somewhere else. Also, I think there's in-tree code that does "foo->compatible[0]" to test if the .compatible member was initialized with something; that would obviously crash if it's a pointer rather than an embedded array.
One thing that might be doable, though requiring quite a bit of work, is getting rid of the silly use of sentinels (quite a lot of the of_device_id arrays have just two elements, so the sentinels are responsible for perhaps 40% of the total memory use) - file2alias already reads the st_size of the symbol and does a "is that a multiple of sizeof(foo)", and "are the last sizeof(foo) bytes all-zeroes" - it's obviously trivial to drop the last test, and process all elements (though ignoring an all-zero element, so we can delete sentinels slowly throughout the tree). That leaves in-tree uses of the of_device_id arrays, where one would need a way to forward the ARRAY_SIZE(), yet continue to stop at an all-zeroes element.
Rasmus
| |