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
to:
> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>