Re: committed memory, mmaps and shms

From: Marcos Dione
Date: Fri Mar 13 2015 - 10:59:04 EST

On Thu, Mar 12, 2015 at 01:56:00PM -0300, Marcos Dione wrote:
> On Thu, Mar 12, 2015 at 11:35:13AM -0400, Michal Hocko wrote:
> > > > On Wed 11-03-15 19:10:44, Marcos Dione wrote:
> I think that what I'm trying to do is figure out what each value
> represents and where it's incuded, as if to make a graph like this
> (fields in /proc/meminfo between []'s; dots are inactive, plus signs
> active):
> RAM swap other (mmaps)
> |------------------------------|-----------------------------|-------------...
> |.| kernel [Slab+KernelStack+PageTables+?]
> |.| buffers [Buffers]
> | . . . . .. .| swap cached (not necesarily like this, but you get the idea) (I'm assuming that it only includes anon pages, shms and private mmaps) [SwapCached]
> |++..| resident annon (malloc'ed) [AnonPages/Active/Inactive(anon)]
> |+++....+++........| cache [Cached/Active/Inactive(file)]
> |+++...| (resident?) shms [Shmem]
> |+++..| resident mmaps
> |.....| other fs cache
> |..| free [MemFree]
> |.............| used swap [SwapTotal-SwapFree]
> |...............| swap free [SwapFree]

Did I get this right so far?

> > > I understand what /proc/sys/vm/overcommit_memory is for; what I
> > > don't understand is what exactly counted in the Committed_AS line in
> > > /proc/meminfo.
> >
> > It accounts all the address space reservations - e.g. mmap(len), len
> > will get added. The things are slightly more complicated but start
> > looking at callers of security_vm_enough_memory_mm should give you an
> > idea what everything is included.
> > How is this number used depends on the overcommit mode.
> > __vm_enough_memory would give you a better picture.
> >
> > > I also read Documentation/vm/overcommit-accounting
> >
> > What would help you to understand it better?

I think it's mostly a language barrier. The doc talks about of how
the kernel handles the memory, but leaves userland people 'watching from
outside the fence'. From the sysadmin and non-kernel developer (that not
necesarily knows all the kinds of things that can be done with
malloc/mmap/shem/&c) point of view, this is what I think the doc refers

> How It Works
> ------------
> The overcommit is based on the following rules
> For a file backed map

mmaps. are there more?

> SHARED or READ-only - 0 cost (the file is the map not swap)
> PRIVATE WRITABLE - size of mapping per instance
> For an anonymous

malloc'ed memory

> or /dev/zero map

hmmm, (read only?) mmap'ing on top of /dev/zero?

> SHARED - size of mapping

a shared anonymous memory is a shm?

> PRIVATE READ-only - 0 cost (but of little use)
> PRIVATE WRITABLE - size of mapping per instance

I can't translate these two terms, unless the latter is the one
refering specifically to mmalloc's. I wonder how could create several
intances of the 'same' mapping in that case. forks?

> Additional accounting
> Pages made writable copies by mmap

Hmmm, copy-on-write pages for when you write in a shared mmap? I'm
wild guessing here, even when what I say doesn't make any sense.

> shmfs memory drawn from the same pool

Beats me.

> Status
> ------

This section goes back mostly to userland terminology.

> o We account mmap memory mappings
> o We account mprotect changes in commit
> o We account mremap changes in size
> o We account brk

This I know is part of the implementation of malloc.

> o We account munmap
> o We report the commit status in /proc
> o Account and check on fork
> o Review stack handling/building on exec
> o SHMfs accounting
> o Implement actual limit enforcement
> To Do
> -----
> o Account ptrace pages (this is hard)

I know ptrace, and this seems to hint that ptrace also uses a good
amount of pages, but in normal operation I can ignore this.

In summary, so far:

* only private writable mmaps are counted 'once per instance', which I
assume it means that if the same process uses the 'same' mmap twice (two
instances), then in gets counted twice, beacuase each instance is
separated from the other.

* malloc'ed and shared memory, again once per instance.

* those two things I couldn't figure out.

Now it seems too simple! What I'm missing? :) Cheers,

-- Marcos.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at