4 ms·

> The “cached” memory includes tmpfs and ramfs for seemingly no reason. If you're curious why that is by the way, it's because that's actually how these are im

> The “cached” memory includes tmpfs and ramfs for seemingly no reason. If you're curious why that is by the way, it's because that's actually how these are implemented (tmpfs/ramfs is just a mount to a filesystem where the files never get marked clean[1]) [1]: https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt https://www.kernel.org/doc/Documentation/filesystems/ramfs-r...

drdexebtjl 3mo ago
That’s clever. Makes for terrible UX, though. AFAIK the only way for you to figure out how much of your disks is actually cached involves enumerating all tmpfs and ramfs mounts, summing their sizes, and subtracting the sum from the cache size reported by the kernel.
- jkrejcha 3mo ago
  Ostensibly you could subtract "Shmem"[1] in /proc/meminfo from the cached value... maybe? Do agree it's not the best UX and utilities should probably do a better job at showing that [1]: https://man7.org/linux/man-pages/man5/proc_meminfo.5.html https://man7.org/linux/man-pages/man5/proc_meminfo.5.html
- Joker_vD 3mo ago
  Well, what's the alternative? Invent a new type of memory reservations specifically to account for tmpfs/ramfs mounts? That'd violate your own stated desired goal of > The OS should just expose a counter for available memory instead of having applications understand every type of memory reservation.
  - drdexebtjl 3mo ago
    I don’t see how it contradicts my goal. I want memory counters that abstract away kernel behavior that the application has no business accounting for.
    - Joker_vD 3mo ago
      The applications, frankly, have no business accounting any memory at all outside of what they use themselves via sbrk/mmap.
      - drdexebtjl 3mo ago
        I think a memory pressure indicator is useful. For example, if you’re writing a garbage collector, you can choose to hold off from returning pages back to the kernel when the system is under low pressure, and do this more often under high pressure.
        Joker_vD 3mo ago
        That's very, very marginally useful. If your application recently ran GC when the system was under low pressure and freed a bunch of pages (and still holds to them), and then some other application suddenly acquires a lot of memory, your application won't free those pages until next GC happens. Which most likely won't until you've used up all those freed pages, and at that point a lot of swapping will already have had happen. Explicitly set per-application upper bounds à la GOMEMLIMIT and Java's -Xmx, together with cgroup's enforcement, seem to be much more useful in practice. Or there was a proposal for some sort of SIGLOWEM signal that would be sent to all processes in the system (with default disposition of "do nothing") that'd allow applications to release some of its non-vital memory holdings: also a much more timelier notification.

drdexebtjl 3mo ago

That’s clever. Makes for terrible UX, though. AFAIK the only way for you to figure out how much of your disks is actually cached involves enumerating all tmpfs and ramfs mounts, summing their sizes, and subtracting the sum from the cache size reported by the kernel.

jkrejcha 3mo ago
Ostensibly you could subtract "Shmem"[1] in /proc/meminfo from the cached value... maybe? Do agree it's not the best UX and utilities should probably do a better job at showing that [1]: https://man7.org/linux/man-pages/man5/proc_meminfo.5.html https://man7.org/linux/man-pages/man5/proc_meminfo.5.html
Joker_vD 3mo ago
Well, what's the alternative? Invent a new type of memory reservations specifically to account for tmpfs/ramfs mounts? That'd violate your own stated desired goal of > The OS should just expose a counter for available memory instead of having applications understand every type of memory reservation.
- drdexebtjl 3mo ago
  I don’t see how it contradicts my goal. I want memory counters that abstract away kernel behavior that the application has no business accounting for.
  - Joker_vD 3mo ago
    The applications, frankly, have no business accounting any memory at all outside of what they use themselves via sbrk/mmap.
    - drdexebtjl 3mo ago
      I think a memory pressure indicator is useful. For example, if you’re writing a garbage collector, you can choose to hold off from returning pages back to the kernel when the system is under low pressure, and do this more often under high pressure.
      - Joker_vD 3mo ago
        That's very, very marginally useful. If your application recently ran GC when the system was under low pressure and freed a bunch of pages (and still holds to them), and then some other application suddenly acquires a lot of memory, your application won't free those pages until next GC happens. Which most likely won't until you've used up all those freed pages, and at that point a lot of swapping will already have had happen. Explicitly set per-application upper bounds à la GOMEMLIMIT and Java's -Xmx, together with cgroup's enforcement, seem to be much more useful in practice. Or there was a proposal for some sort of SIGLOWEM signal that would be sent to all processes in the system (with default disposition of "do nothing") that'd allow applications to release some of its non-vital memory holdings: also a much more timelier notification.