On 11/23/2010 02:54 PM, Lennart Poettering wrote: > On Tue, 23.11.10 13:41, Nicholas Miell (nmiell@xxxxxxxxx) wrote: >> On 11/23/2010 12:48 PM, Lennart Poettering wrote: >>> Heya! >>> >>> I hereby want to let everybody know that in the next days I will turn on >>> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance >>> with the following accepted F15 feature: >>> >>> https://fedoraproject.org/wiki/Features/var-run-tmpfs >>> >> >> Is this actually an improvement? > > See the spec page. The spec page says it'll be better, but is very vague as to why. Basically, I'm looking for a "Doing this will keep $X kilobytes permanently pinned in RAM (in the form of dentry and inode structs) and $Y bytes in RAM or swap (in the form of file data pages), of which $Z bytes is wasted (due to the fixed page size) and this is {worth it, not worth it} due to the $N millisecond improvement in boot times." i.e. an acknowledgment that somebody thought about the trade-offs and decided it is the right thing to do. > I think the fact that we get less disks accesses (just think noatime and > stuff for the files dropped there) is more interesting than using the > absolute minimal amount of memory. They're already on a relatime mount, and don't bind mounts support noatime now? (e.g. mount --bind /var/run /var/run; mount -o remount,noatime /var/run) >> I know that dentries and inodes for regular filesystems can be discarded >> from RAM if they're not in use, is that the case for a tmpfs? >> How often are the files in /var/run and /var/lock accessed? Is the >> kernel likely to discard them? > > Note that under memory pressure tmpfs can be swapped out. The data pages can, but the inodes and dentries are permanently pinned in unswappable kernel memory. >> Files in /var/run tend to be 4 or 5 bytes in length, does that mean they >> each use an entire page of RAM or swap? There are vastly fewer swap >> pages than there are filesystem blocks, isn't this less efficient? > > Yes, normal files will take up 4k if they contain data. But that's > something that could be fixed and which would not only be useful for > this usecase but the much heavier existing users of tmpfs such as udev. That's a hypothetical future feature, which isn't exactly relevant to the issue at hand. (And I think mmap() would make that really complicated.) If anything, it's an argument that udev should be moved off of a tmpfs, but that's another discussion entirely. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
