Sysfs and small memory machines [LWN.net]

William Lee Irwin recently tried the 2.6.0-test kernel on a system limited to 16MB of memory. In the modern world, that is a shockingly small amount of RAM, just slightly above storing your data on an abacus. There are people out there, however, who are doing their best to get work done on limited hardware, and, as Andrew Morton says, "we should try to not suck in this situation." William's results indicate that some work is still required for 2.6 to perform adequately on low-end hardware.

One of the more striking results from this test is that a substantial chunk of the system's memory is consumed by the inode and dentry caches. Those caches, in fact, took up over 10% of the memory which was available at boot time. If some way could be found to reduce the size of the inode and dentry caches, enough memory would be freed to make a noticeable difference on low-memory systems.

The culprit in this case is sysfs. Each entry in sysfs creates an inode and a directory entry, and both are pinned into memory for the life of the system. Pinning the entries is a standard way of creating virtual filesystems in the kernel; it frees the code from the need to create any sort of backing store for the filesystem. This scheme works less well when a filesystem can have thousands of entries, however. Even a minimal system's sysfs directory can have several hundred files and directories, and there is a clear intent to add many more.

One approach to the problem is to simply get rid of sysfs; Andrew Morton has posted a patch which adds a "nosysfs" boot-time option. This capability may be of interest to creators of embedded systems and such, but it is hard to see its utility extending much beyond that. Sysfs is becoming an increasingly important communications channel between user and kernel space; it can't just be ripped out without breaking things.

So the kernel hackers will have to figure out how to preserve sysfs while trimming its memory requirements. One set of patches posted recently tried to achieve this goal by adding a real, in-kernel backing store for sysfs. The patch did not get very far, however, because it made the kobject structure significantly bigger. The real solution will probably involve a bit of clever filesystem hacking. The internal kobject hierarchy contains the information that is really needed to implement sysfs; the existing cached inodes and dentries just make it work easily. But those cached entries - especially those for the attributes that make up the bottom leaves of sysfs - could be generated on demand when user space actually needs them. It will take some work, but users of small systems will doubtless be thankful for the result.

The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:

Note: you can avoid this step in the future by logging into your LWN account.