summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2011-01-08 00:47:56 +0100
committerThomas Schwinge <thomas@schwinge.name>2011-01-08 00:47:56 +0100
commit44b308531e8c1823ecdcad17488c4e5eea36c19a (patch)
tree8a279d0c13eff380a24b3fc11a95c896cfafc39a
parent8c1d42cc00872bc429b5e959467434df2faac463 (diff)
open_issues/mach_tasks_memory_usage: New. IRC, #hurd, 2011-01-06.
-rw-r--r--open_issues/mach_tasks_memory_usage.mdwn100
1 files changed, 100 insertions, 0 deletions
diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn
new file mode 100644
index 00000000..12758dbc
--- /dev/null
+++ b/open_issues/mach_tasks_memory_usage.mdwn
@@ -0,0 +1,100 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+IRC, #hurd, 2011-01-06.
+
+ <antrik> hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but
+ the sum of all RSS is <300 MiB... what's the rest?
+ <braunr> kernel memory ?
+ <braunr> the zone allocator maybe
+ <braunr> or the page cache simply
+ <antrik> braunr: which page cache? AIUI, caches are implemented by the
+ individual filesystem servers -- in which case any memory used by them
+ should show up in RSS
+ <antrik> also, gnumach is listed among other tasks, so I'd assume the
+ kernel memery also to be accounted for
+ <braunr> antrik: no, the kernel maintains a page cache, very similar to
+ what is done in Linux, and almost the same as in FreeBSD
+ <braunr> the file system servers are just backing stores
+ <braunr> the RSS for the gnumach tasks only includes kernel memory
+ <braunr> I don't think the page cache is accounted for
+ <braunr> because it's not really kernel memory, it's a cache of user space
+ memory
+ <antrik> apparently my understanding of Mach paging is still (or again?)
+ rather incomplete :-(
+ <antrik> BTW, is there any way to find out how much anonymous memory a
+ process is using? the "virtual" includes discardable mappings, and is
+ thus not very helpful...
+ <antrik> (that applies to Linux as well though)
+ <braunr> can you provide an example of the output of vmstat please ?
+ <braunr> I don't have a Hurd VM near me
+ <antrik> olaf@alien:~$ vmstat
+ <antrik> pagesize: 4K
+ <antrik> size: 501M
+ <antrik> free: 6.39M
+ <antrik> active: 155M
+ <antrik> inactive: 310M
+ <antrik> wired: 29.4M
+ <antrik> zero filled: 15.3G
+ <antrik> reactivated: 708M
+ <antrik> pageins: 3.43G
+ <antrik> pageouts: 1.55G
+ <antrik> page faults: 26844574
+ <antrik> cow faults: 3736174
+ <antrik> memobj hit ratio: 92%
+ <antrik> swap size: 733M
+ <antrik> swap free: 432M
+ <antrik> interesting... closing a single screen window temporarily raises
+ the "free" value by almost 10 MB
+ <antrik> I guess bash is rather hungry nowadays ;-)
+ <braunr> antrik: I guess the only way is using pmap or looking into
+ /proc/<pid>/maps
+ <braunr> but it won't give you the amount of physical memory used by
+ anonymous mappings
+ <antrik> nah, I don't even want that... just like to know how much memory
+ (RAM+swap) a process is really using
+ <braunr> antrik: then the RSS field is what you want
+ <antrik> OTOH, anonymous doesn't include program code or other actively
+ used mappings... so not very useful either
+ <antrik> nah, RSS doesn't count anything that is in swap
+ <braunr> well
+ <braunr> don't you have a SWAP column ?
+ <braunr> hm
+ <braunr> i guess not
+ <braunr> antrik: why do you say it doesn't include other actively used
+ mappings ?
+ <braunr> antrik: and the inclusion of program code also depends on the
+ implementation of the ELF handler
+ <braunr> I don't know how the hurd does that, but some ELF loaders use
+ anonymous memory for the execution view
+ <antrik> well, if a program maps a data file, and regularily accesses parts
+ of the file, they won't occupy physical RAM all the time (and show up in
+ RSS), but they are not anonymous mappings. similar to program code
+ <braunr> then this anonymous memory is shared by all processes using that
+ code
+ <antrik> oh, interesting
+ <antrik> is it really a completely distinct mapping, rather than just COW?
+ <braunr> the first is
+ <braunr> others are COW
+ <antrik> so if a program loads 200 MB of libraries, they are all read in on
+ startup, and occupy RAM or swap subsequently, even if most of the code is
+ never actually run?...
+ <kilobug> library code should be backed by the library file on disk, not be
+ swap
+ <braunr> depends on the implementation
+ <braunr> I guess most use the file system backend
+ <braunr> but in the Hurd, ext2fs.static and ld.so.1 use anonymous memory
+ <braunr> (that's the case for another reason, still, I don't think the
+ report in top/ps clearly indicates that fact)
+ <kilobug> braunr: yeah for bootstrapping issues, makes sense
+ <braunr> it may also depends on the pic/pie options used when building
+ libraries