3:41 p.m.
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?
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?
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?
4:54 p.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23.11.10 13:41, Nicholas Miell (nmiell(a)gmail.com) 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.
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.
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.
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.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:15 p.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/23/2010 02:54 PM, Lennart Poettering wrote:
On Tue, 23.11.10 13:41, Nicholas Miell (nmiell(a)gmail.com) 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.
8:30 p.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 23 Nov 2010, Nicholas Miell wrote:
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.
Personally, I think its worth it just because a rebooted/crashed system starts
with a clean /var/run and /var/lock. Too often I've seen things not startup
based on a stale pid file.
Paul
1:08 p.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 5:15 PM, Nicholas Miell <nmiell(a)gmail.com> wrote:
On 11/23/2010 02:54 PM, Lennart Poettering wrote:
> On Tue, 23.11.10 13:41, Nicholas Miell (nmiell(a)gmail.com) 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.
How about "Less un-necessary crap scribbled all over the filesystem"?
In an age of Live CD/DVD/USB, and flash-based storage devices, cheap
and free filesystem writes can no longer be taken for granted. Its
amazing how much state is spread around the filesystem. Persistent
network rules in /etc/udev/rules.d/, and dhcp client state in
/var/lib/dhclient/ are just a few examples of what has caused me
endless trouble swapping a HD between a few different systems while I
evaluate which works best as a MythTV system. I end up having to clear
the persistent net rules, the client-side lease state, AND the lease
in my router just to get a different motherboard to take the same
fixed IP address lease on eth0. (Which MythTV gets angry if it doesn't
have) State, state saved everywhere...
In an age where "Live" systems are a major use case, why are we saving
all this random state all over that necessitates complexity like
filesystem overlays (how much ram does THAT all eat on a running Live
system?) when its all just going to get tossed out anyway?
7:41 p.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 11:54:47PM +0100, Lennart Poettering wrote:
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.
Less disk access at startup, or in general somehow? Optimizing for startup
performance over general performance does not seem so good. But this is
really about elegance rather than resource usage, right?
Currently, /var/run and /var/lock on my rawhide desktop system take up 364K.
385K on another rawhide system. (Blocksize of 4k.) I think we can spare that
in this day and age if we get a reasonable benefit in return.
Meanwhile, NetworkManager is doing absolutely nothing for me, and is taking
up a USS of 65.3M. If we're gonna tilt at memory consumption windmills, how
about we take a look at that one?
(NetworkManager is awesome on my _laptop_, by the way. Wouldn't dream of
living without it.)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:09 a.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, 2010-11-23 at 20:41 -0500, Matthew Miller wrote:
Meanwhile, NetworkManager is doing absolutely nothing for me, and is
taking
up a USS of 65.3M. If we're gonna tilt at memory consumption windmills, how
about we take a look at that one?
Are you sure that's right? According to htop, it only uses 3MB, here.
(nm-applet is another 10MB).
(NetworkManager is awesome on my _laptop_, by the way. Wouldn't
dream of
living without it.)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:49 a.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Tue, Nov 23, 2010 at 10:09:25PM -0800, Adam Williamson wrote:
> Meanwhile, NetworkManager is doing absolutely nothing for me,
and is
> taking up a USS of 65.3M. If we're gonna tilt at memory consumption
> windmills, how about we take a look at that one?
Are you sure that's right? According to htop, it only uses 3MB, here.
(nm-applet is another 10MB).
I'm not sure it's *right*, but I'm sure it's *accurate* -- that's what
I'm
seeing. (No nm-applet currently running, btw.)
On my (F13) laptop, it seems to be using only a reasonable 1.9M USS, while
nm-applet is 14.4M.
Anyway, even at 3M, that's an order of magnitude more than the amount we're
talking about with /var/{run,lock}. And while NetworkManager is fun to pick
on, I'm sure there's dozens of other places where we've consumed a meg of
memory without blinking. I've apparently got deja-dup-monitor running, for
example, even though I do my backups a different way.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:32 a.m.
New subject: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 24/11/10 01:41, Matthew Miller wrote:
On Tue, Nov 23, 2010 at 11:54:47PM +0100, Lennart Poettering wrote:
> 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.
Less disk access at startup, or in general somehow? Optimizing for startup
performance over general performance does not seem so good. But this is
really about elegance rather than resource usage, right?
Currently, /var/run and /var/lock on my rawhide desktop system take up 364K.
385K on another rawhide system. (Blocksize of 4k.) I think we can spare that
in this day and age if we get a reasonable benefit in return.
Meanwhile, NetworkManager is doing absolutely nothing for me, and is taking
up a USS of 65.3M. If we're gonna tilt at memory consumption windmills, how
about we take a look at that one?
(NetworkManager is awesome on my _laptop_, by the way. Wouldn't dream of
living without it.)
Here is the RAM usage on my 11 day uptime F14 laptop
$ sudo ps_mem.py¹
Private + Shared = RAM used Program
1.9 MiB + 252.5 KiB = 2.1 MiB NetworkManager [updated]
7.0 MiB + 1.6 MiB = 8.6 MiB nm-applet [updated]
I notice both were updated so restarting gives:
$ sudo ps_mem.py
1.4 MiB + 290.0 KiB = 1.7 MiB NetworkManager
2.6 MiB + 1.3 MiB = 3.9 MiB nm-applet
[1] http://www.pixelbeat.org/scripts/ps_mem.py
4902
days inactive
4903
days old
8 comments
7 participants
participants (7)
-
Adam Williamson -
Callum Lerwick -
Lennart Poettering -
Matthew Miller -
Nicholas Miell -
Paul Wouters -
Pádraig Brady