On Wed, 28 Jun 2006, Greg Bledsoe wrote:
>
> Thank you. This information is extremely difficult to find without
> digging into kernel code, which I certainly wish I had time to do, but
> don't, and particulars of how many aspects of memory management happen
> seems to be nonexistant. I would like to document this aspect, at
> least, as well as I am able and post somewhere to add to the worlds'
> global knowledge pool on this subject, and prevent the lkml from
> getting bugged about this anymore.
The problem you will find with any document of this kind is that the
kernel is constantly changing. Who's going to keep the document up
to date?
>
> This leads me to the question though, of how the kernel keeps track of
> this information overall to report accurately via free and vmstat.
free reads /proc/meminfo which your can see how this is done from
linux-2.6.17/fs/proc/proc_misc.c: meminfo_read_proc
vmstat gets its info from /proc/stat and you can see how that is done
from linux-2.6.17/fs/proc/proc_misc.c: show_stat
> Does it just keep an overall count on the fly as memory is allocated?
Yes and this is not process specific, but low level from any allocation.
> And, getting ahead of myself, if that can be done, is it just
> considered too expensive to keep a similar acount for each proccess?
What do you really want to know? A process is abstract. It's memory
can be physical, shared, a file or in swap. Its memory may not even be
allocated until it actually tries to use it. So what exactly do you
need?
I'm bringing this up because too many managers want this information
and they don't know why. Why do they want to know how much memory a
process is using? Is it to see if it has a memory leak? Is it just
to know how much it uses? If that is the case, then the virtual map
from /proc/PID/maps should be a good way to know. It shows the shared
libraries, so you can take that into account. And all the other memory
it maps has the potential to be real. Otherwise, why would it map it?
Chances are, a process wont use all the memory shown in maps, but
if you are afraid of running out of memory, then take the conservative
approach and give that answer.
> That seems to be what I am hearing in previous lkml discussions.
>
> Also, since it seems virtually impossible to get this data on a
> per-process basis, does smap suffer from these same difficulties, as
> it seems to calculate this information when asked, and not keep it
> from process start time.
I don't know anything about smap.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
