On Thu, Oct 5, 2017 at 8:44 PM, Rob Herring <robh@xxxxxxxxxx> wrote: > On kernels with a minimal config and a RAM target in the 100s of KB, DT > is quite a hog of runtime memory usage. How much is dependent on how many > nodes and properties in the DT which have a corresponding struct device_node > and struct property in the kernel. Just skipping disabled nodes saves a > lot by not creating the device_nodes in the first place[1], but there's > more low hanging fruit by making some of the fields in struct property and > struct device_node optional. With the changes here, the memory usage goes > from 17KB to under 8KB on QEMU's ARM virt machine which is a relatively > small DT. > > The majority of the diffstat here is just moving all the kobject/sysfs > related code to its own file so we can avoid adding a bunch of ifdefs. > > There's more drastic approaches we could take such as doing the > unflattening at build time and storing the bulk of the unflattened tree > as const data. Grant also has some ideas on storing properties as ids > instead. He's explained it to me, but I still don't understand it. It was a two part idea. The first part is to start using numerical IDs for property names instead of strings. The DTB format kind of already does this because all the property names are stored in the string table at the end of the dtb. The actual properties just reference an offset into the string table. If we predefined ids for some property names (reg, compatible, status, etc.), then we could have a variant of the of_property_* API to find properties by numerical ID instead of by strcmp(). The second idea is to eliminate struct property entirely and always store a node's properties as a single DTB tagged list blob. It would reduce the space required at the expense of processing time when parsing the blob. The upshot is the property list could be left in a flash-resident copy of the DTB. Details need to be investigated, and it would be much more invasive than what Rob has been able to do here. It may not be worth the effort. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
