[CrociDB]

The thing is it's easy to define free, unused memory. But a lot of the used memory is your system caching stuff that would be free if you needed more than what's actually free. So you can see you have 1g of free memory out of your 4g, but then you allocate 3g and it will do without a sweat and you'd be confused. So you have to go and dig for what those caches are and report that they're effectively free too.

[drdexebtjl]

Instantly reclaimable disk caches should count as available, and they do.

This isn’t hard. The OS should just expose a counter for available memory instead of having applications understand every type of memory reservation.

edit:

Linux does this, but it has its own share of issues with memory counters. The “cached” memory includes tmpfs and ramfs for seemingly no reason.

[jkrejcha]

> 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-r...

[drdexebtjl]

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.

[Joker_vD]

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]

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]

The applications, frankly, have no business accounting any memory at all outside of what they use themselves via sbrk/mmap.

[jkrejcha]

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

[killerstorm]

That metric would give you a number of bytes which can be used for pages not backed by files, but it won't give you actual memory usage statistics:

It won't count executable pages and memory-mapped file use as "used" memory, so your system might display gigabytes "free" when it's starving, executables getting paused when code pages are paged-in from disk.

It's just less useful than what's displayed now. "Everyone is doing it wrong" is usually a signal that you're missing something.

[man8alexd]

Linux MemAvailable from /proc/meminfo is just an estimation calculated as an arbitrary percentage (50%) of free and potentially reclaimable memory.

You can't determine how much of the memory can actually be reclaimed under memory pressure until you try to reclaim it.

[drdexebtjl]

> You can't determine how much of the memory can actually be reclaimed under memory pressure until you try to reclaim it.

Yes, and I’m arguing that we should be able to, by having the kernel keep track.

[man8alexd]

The kernel keeps track of active/inactive pages by scanning page tables during the reclaim process. It only scans until it finds enough inactive pages to reclaim. Scanning all pages all the time is very expensive from a performance point of view.