Hacker News Reader

Comment by makomk | Hacker News Reader

This is actually wrong. For some reason (probably because of the way it's implemented internally) Linux includes shared memory allocations in the "cached" figure. If you calculate the amount of free memory using "free -m" in the way this web page advises, you'll think that memory is free when it really isn't - unlike true cache, shared memory cannot be discarded when the space is needed for something else.

I've actually had buggy desktop applications use several gigabytes of RAM as shared memory, so this can make a big difference.

View on HN

Linux also counts files on tmpfs as part of the cache number--it's really annoying that no number in top can serve to show you a decent approximation of how many page-size malloc()s you can do before OOM (with overhead and fragmentation and so on, of course it's infeasible to get an exact number).

It's worse. No line of /proc/meminfo has that value, and since not all of the cache can be instantly discarded (I didn't know that), I don't see any combination of them that would help.

That sentence:

> There are no downsides, except for confusing newbies.

Just isn't true. There is the downside that we can't know how much memory is available.

Yeah, and obviously some (though not all) forms of shared memory are actually implemented using tmpfs behind the scenes which makes life even more interesting. I think the problem I encountered involved SysV shared memory which isn't backed by tmpfs and does show up in /proc/meminfo, whereas other types may not.

Can't you use something like this: https://raw.github.com/pixelb/ps_mem/master/ps_mem.py

I use that to help determine "least incorrect" ram usage on linux. It is ok, maybe not perfect but it at least lets you get a better view on memory.

So... what exactly do I have to type on my command line to see how much RAM can actually be used by applications?

> For some reason (probably because of the way it's implemented internally)

(this is tautologically true)

he means the rationale behind developing it that way was due to the way other stuff is laid out internally, not "the number shows up because the existing code codes for it and causes it to show up".

I used to have a similar problem on OS X. When I was working on a 32-bit app that could eat tons of memory, I ended up using a bunch of weird heuristics and allocation tracking just to get a probable assurance that the program could recover properly from running out of address space.

Reply on news.ycombinator.com