mirror of
https://github.com/lm-sensors/lm-sensors.git
synced 2026-10-08 09:04:39 +07:00
Jean Delvare
b7b2c45789
When gathering the attributes of each hwmon chip, libsensors uses a temporary structure in memory to order and group all the attributes into features. This temporary structure used to be a single array with room for every possible attribute/subfeature. While simple, this approach required to predefine a maximum number of per-type sensor that could be handled. In order to get rid of this arbitrary limit, which we hit and had to raise three times already, I changed the temporary structure to an array of dynamically allocated per-type subattribute arrays. This lets us not allocate any memory for types which aren't implemented by a given chip, and more importantly, this lets us reallocate room for more attributes of a given type as needed. I decided to allocate chunks of 8 attributes at a time, as this seemed a good compromise between two frequent reallocations and over-provisioning. It could be tweaked if needed. Icing on the cake, I benchmarked this change on two different systems and it results in performance gains. The total heap usage as reported by valgrind is down by 50% on average, with peak memory consumption (as reported by valgrind's massif) also down by 43% on average. The total instructions count (as reported by valgrind's callgrind) is down by 11% on average, with measured execution time also down by a few percents. Valgrind rocks, BTW. I have some ideas to optimize the memory allocations further, but I do not expect such a huge gain from them. They may not even improve peak memory consumption as massif shows the peak is somewhere else now at least in some cases. Signed-off-by: Guenter Roeck <linux@roeck-us.net>