5 ms·

First, he forgets about the sharing memory which needs to be subtracted from the resident number, since that memory is shared by multiple applications, so gvim

First, he forgets about the sharing memory which needs to be subtracted from the resident number, since that memory is shared by multiple applications, so gvim eats not 27mb but only 14mb which is a very respectable number in my opinion. Second, I just have gone through a long-awaited "Arch weekend" and finished building a fully functional ArchLinux machine. It was definitely not "optimizing for the wrong thing". Arch allows you to pick system components you actually want, as opposed to Ubuntu's approach to installing everything you may need. It speeds up your boot/reboot/resume time and it does run about 30% leaner on RAM when it reaches feature parity with my Ubuntu installation.

aw3c2 17y ago
Third, he applies a quote from Linus Torvalds about the Linux kernel to distributions (or programs).
jbert 17y ago
Sharing doesn't equate with resident, it equates with virtual memory. You can have a process with 1GB of vm, of which 100MB is shared with other processes but which has only 10MB resident (hmm...am I wrong? are shared pages never evicted from RAM?) You can use 'exmap' (if it still compiles) to pull per-page statistics from your kernel and apportion the memory cost of a shared page pro-rata to all the processes, look at what is resident and what is not, and get an "Effective Resident" figure for each process. (You can then look at the process breakdown by shared lib, and the shared libs by ELF symbol).
- old-gregg 17y ago
  jbert, you are not wrong, vmem includes everything. But shared libs have a much higher chance to be in the working set simply because multiple processes are using them. I doubt that clib or any of GTK ever get swapped, so it is safe to assume that on most non-starved systems "real" memory consumption = RES-SHR.
  - jbert 17y ago
    I think I am wrong. I now think top's 'SHR' isn't the "total amount of virtual memory shared", it's "amount of RES which is shared". (Hmm...but my test could be conflating "RES" memory with "allocated" VM (memory which is backed by something, be it swap or RAM). So you can indeed substract SHR from RES to get a feel for per-proc RES. (But that 'feel' doesn't tell you how many procs that SHR is shared with, and worse, which ones. If firefox fork()d then all it firefox-specific code pages would contribute to SHR, but you'd really want to account for them in the "firefox application"). (I'd also definitely expect chunks of libc and gtk libs to not be resident, primarily because they're code pages containing only code paths not yet chased on this box. And only one app has used those pages, do you really want to call that 'shared'?)
easp 17y ago
Subtracting shared from resident gives a best case, I think, because the "shared" memory isn't necessarily shared. The thing that drives me nuts is the people who freak out over Apache's memory usage because they add up the resident size of each worker. Then they go to the trouble of getting FCGI working with nginx or lighttp, all to save, at best a dozen MB or so, and at worst, to use more memory, because they start the fcgi workers in such a way that they don't share memory for things like the PHP opcode cache. Then they evangelize their ignorance.

aw3c2 17y ago

Third, he applies a quote from Linus Torvalds about the Linux kernel to distributions (or programs).

jbert 17y ago

Sharing doesn't equate with resident, it equates with virtual memory. You can have a process with 1GB of vm, of which 100MB is shared with other processes but which has only 10MB resident (hmm...am I wrong? are shared pages never evicted from RAM?) You can use 'exmap' (if it still compiles) to pull per-page statistics from your kernel and apportion the memory cost of a shared page pro-rata to all the processes, look at what is resident and what is not, and get an "Effective Resident" figure for each process. (You can then look at the process breakdown by shared lib, and the shared libs by ELF symbol).

old-gregg 17y ago
jbert, you are not wrong, vmem includes everything. But shared libs have a much higher chance to be in the working set simply because multiple processes are using them. I doubt that clib or any of GTK ever get swapped, so it is safe to assume that on most non-starved systems "real" memory consumption = RES-SHR.
- jbert 17y ago
  I think I am wrong. I now think top's 'SHR' isn't the "total amount of virtual memory shared", it's "amount of RES which is shared". (Hmm...but my test could be conflating "RES" memory with "allocated" VM (memory which is backed by something, be it swap or RAM). So you can indeed substract SHR from RES to get a feel for per-proc RES. (But that 'feel' doesn't tell you how many procs that SHR is shared with, and worse, which ones. If firefox fork()d then all it firefox-specific code pages would contribute to SHR, but you'd really want to account for them in the "firefox application"). (I'd also definitely expect chunks of libc and gtk libs to not be resident, primarily because they're code pages containing only code paths not yet chased on this box. And only one app has used those pages, do you really want to call that 'shared'?)

easp 17y ago

Subtracting shared from resident gives a best case, I think, because the "shared" memory isn't necessarily shared. The thing that drives me nuts is the people who freak out over Apache's memory usage because they add up the resident size of each worker. Then they go to the trouble of getting FCGI working with nginx or lighttp, all to save, at best a dozen MB or so, and at worst, to use more memory, because they start the fcgi workers in such a way that they don't share memory for things like the PHP opcode cache. Then they evangelize their ignorance.