summaryrefslogtreecommitdiff
path: root/open_issues/mach_tasks_memory_usage.mdwn
blob: 12758dbc7807dbdbaf900ecf653924e4b24a2d28 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
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