Hi Hartmut, > I've just created a couple sysfs files in order to find out, and the > conclusion is that each additional sysfs file reduces the remaining free > memory by something on the order of 90-95 bytes. > It turns out that the memory reported by 'free' varies quite a bit between > calls, which disturbs somewhat the precision of this measurement. I had to > create 10000 sysfs files in order to get a statistically significant > result. Now this result is correct on the 10% level, which I think is good > enough for our discussion. > For this experiment, I used the same callback function for all sysfs > files, so each additional file has just one SENSOR_DEVICE_ATTR struct > definition and a device_create_file() call, but no extra supporting code. > This is the typical situation for the individual alarm files, I guess. Yes, you tested the right thing, thanks for reporting your results. I have been conducting a similar investigation but on the theoretical front. It seems that the amount of memory required by each additional sysfs file (not counting the callbacks and creation) is the size of stuct sysfs_dirent, plus 4 bytes (not sure why, most probably an internal slab implementation detail.) This is 40 + 4 = 44 bytes on x86, 72 + 4 = 76 bytes on x86_64. I don't know why your measurement suggests larger allocations. But even with your value of 90-95 bytes it's still a rather small value. > With current DRAM prices, 100 extra bytes correspond to extra costs of > around 1e-5 EUR or USD for each additional file, which I think is > tolerable. I don't think this is a matter of price, but more of a matter of consumed memory on already designed/deployed systems, especially on embedded systems. Other systems typically have over 3000 sysfs files, so a dozen more or less really doesn't change anything. If we consider the w83627hf driver as an example (being one of the drivers with the higher number of alarm+beep files in my individual files model) the additional memory consumption is (on x86) 44 * 33 = 1452 bytes. This really isn't much, even for an embedded system. Such systems will typically have between 600 and 1600 sysfs files already, 33 more or less (worse case) still aren't that much. Last, here are the figures I promised some days ago: Before my individual alarm files patches: text data bss dec hex filename 6101 1344 4 7449 1d19 drivers/hwmon/f71805f.o 4848 1052 16 5916 171c drivers/hwmon/lm63.o 5861 1892 36 7789 1e6d drivers/hwmon/lm90.o 15024 1356 16 16396 400c drivers/hwmon/w83627hf.o -rw-r--r-- 1 khali users 24129 2006-03-09 18:52 drivers/hwmon/f71805f.c -rw-r--r-- 1 khali users 18909 2006-03-09 15:23 drivers/hwmon/lm63.c -rw-r--r-- 1 khali users 22806 2006-03-09 15:23 drivers/hwmon/lm90.c -rw-r--r-- 1 khali users 45891 2006-03-09 15:23 drivers/hwmon/w83627hf.c After the patches: text data bss dec hex filename 6357 1696 4 8057 1f79 drivers/hwmon/f71805f.o 5122 1196 16 6334 18be drivers/hwmon/lm63.o 6185 2060 36 8281 2059 drivers/hwmon/lm90.o 16126 2128 16 18270 475e drivers/hwmon/w83627hf.o -rw-r--r-- 1 khali users 25316 2006-03-09 19:04 drivers/hwmon/f71805f.c -rw-r--r-- 1 khali users 20174 2006-03-09 19:04 drivers/hwmon/lm63.c -rw-r--r-- 1 khali users 24235 2006-03-09 19:04 drivers/hwmon/lm90.c -rw-r--r-- 1 khali users 50068 2006-03-09 19:18 drivers/hwmon/w83627hf.c Summary: f71805f: +608 binary ( +8.1%), +1187 source ( +4.9%) lm63: +418 binary ( +7.0%), +1265 source ( +6.6%) lm90: +492 binary ( +6.3%), +1429 source ( +6.2%) w83627hf: +1874 binary (+11.4%), +4177 source ( +9.1%) So the size increase is admittedly not neglectable and greater than I would like, but it isn't (IMHO at least) unaccpeptable either, especially when hardware monitoring drivers are not amongst the largest drivers in the first place. Also note that the number of individual alarm files depends on the number of channels and/or limits the device has, so this approach won't suddenly turn a small driver into a large one. The size increment had to be somehow proportional to the original driver size. If anyone has similar figures for Hans de Goede's proposal, for comparison, I'll be happy to take a look. Thanks, -- Jean Delvare
