How to calculate still available memory programmatically?

[stolze]

Hi all,

I have a system with 32GB physical main memory and only a single application is running on that system, besides the usual system services. Now I would like to know how much more memory I can safely allocate in the application before I run out of physical memory and paging will start. (I want to do this calculation programmatically and if necessary with high frequency.)

The kernel is rather ancient (2.6.16), but that's what I have to work with due to non-technical reasons. I started with /proc/meminfo and the information I can gather from there is something like this:

MemTotal:     32964528 kB
MemFree:       3194788 kB
Buffers:        435456 kB
Cached:       28142944 kB
SwapCached:          0 kB
Active:       13645468 kB
Inactive:     15112868 kB
Dirty:             432 kB
Writeback:           0 kB
AnonPages:      113532 kB
Mapped:          32664 kB
Slab:           964380 kB
CommitLimit:  20691252 kB
Committed_AS:   173780 kB

I read through the (rather brief) description of those elements in Documentation/filesystems/proc.txt but didn't get very far. Now the problem is that I have some shared memory mlock()'d, which must not be treated as available memory.

I think I'll have to sum up MemFree + Buffers + Cached + SwapCached. But adding "Cached" would give me wrong results because the pinned shared memory is counted there. Another idea was to add MemFree + Buffer + Inactive, but there is probably some memory in "Active", which is not pinned and could be made available by the kernel under high memory pressure. But how I can determine that part of "Active", I do not know.

So what's the best approach to come up with the number of bytes/pages that can still be allocated - and committed - for the application before heavy swapping would have to kick in? (I don't care about a few MBs being swapped out occasionally.)

[coopstah13]

parse output of free command, second line tells you available/used memory after subtracting out buffers/cache

[stolze]

Right, except that "free" does nothing else than parsing the content of /proc/meminfo and then summing up MemFree + Buffers + Cached. So I can easily parse the content directly myself and avoid the overhead resulting from fork(), which is an issue in my situation.

Anyway, whether I parse the file myself or parse the output of "free" doesn't change anything with respect to the question about pinned (shared) memory. Which element in /proc/meminfo includes that and how can I make sure I won't count it as available memory while not leaving out anything else that may be made available by the kernel if needed?

[coopstah13]

i'm not sure which does, which is why i pointed you to output of free command

if you are interested, there seems to be a kernel library for meminfo that has a struct with all the things in it that you're looking for meminfo(3) manual page

you could write a simple tiny little kernel module that would expose a file in /proc that you could look at or something else

[stolze]

According to this man page, meminfo() also only parses /proc/meminfo. The description in that man page is even more brief than in the kernel documentation. Unfortunately, I can't add another kernel module because I would loose support for legal reasons.

So what I take from this discussion is that /proc/meminfo only has the documentation that comes with the kernel source itself and no further details are available. I guess I'll have to experiment a bit and rely on those results...

[coopstah13]

Well obviously if it has a struct member that has that memory type then you can calculate it from that file somehow