1. 30 Oct, 2005 2 commits
  2. 05 Sep, 2005 2 commits
    • Mauricio Lin's avatar
      [PATCH] add /proc/pid/smaps · e070ad49
      Mauricio Lin authored
      
      
      Add a "smaps" entry to /proc/pid: show howmuch memory is resident in each
      mapping.
      
      People that want to perform a memory consumption analysing can use it
      mainly if someone needs to figure out which libraries can be reduced for
      embedded systems.  So the new features are the physical size of shared and
      clean [or dirty]; private and clean [or dirty].
      
      Take a look the example below:
      
      # cat /proc/4576/smaps
      
      08048000-080dc000 r-xp /bin/bash
      Size:               592 KB
      Rss:                500 KB
      Shared_Clean:       500 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:        0 KB
      080dc000-080e2000 rw-p /bin/bash
      Size:                24 KB
      Rss:                 24 KB
      Shared_Clean:         0 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:       24 KB
      080e2000-08116000 rw-p
      Size:               208 KB
      Rss:                208 KB
      Shared_Clean:         0 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:      208 KB
      b7e2b000-b7e34000 r-xp /lib/tls/libnss_files-2.3.2.so
      Size:                36 KB
      Rss:                 12 KB
      Shared_Clean:        12 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:        0 KB
      ...
      
      (Includes a cleanup from "Richard Purdie" <rpurdie@rpsys.net>)
      
      From: Torsten Foertsch <torsten.foertsch@gmx.net>
      
      show_smap calls first show_map and then prints its additional information to
      the seq_file.  show_map checks if all it has to print fits into the buffer and
      if yes marks the current vma as written.  While that is correct for show_map
      it is not for show_smap.  Here the vma should be marked as written only after
      the additional information is also written.
      
      The attached patch cures the problem.  It moves the functionality of the
      show_map function to a new function show_map_internal that is called with an
      additional struct mem_size_stats* argument.  Then show_map calls
      show_map_internal with NULL as struct mem_size_stats* whereas show_smap calls
      it with a real pointer.  Now the final
      
      	if (m->count < m->size)  /* vma is copied successfully */
      		m->version = (vma != get_gate_vma(task))? vma->vm_start: 0;
      
      is done only if the whole entry fits into the buffer.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e070ad49
    • Christoph Lameter's avatar
      [PATCH] /proc/<pid>/numa_maps to show on which nodes pages reside · 6e21c8f1
      Christoph Lameter authored
      This patch was recently discussed on linux-mm:
      http://marc.theaimsgroup.com/?t=112085728500002&r=1&w=2
      
      
      
      I inherited a large code base from Ray for page migration.  There was a
      small patch in there that I find to be very useful since it allows the
      display of the locality of the pages in use by a process.  I reworked that
      patch and came up with a /proc/<pid>/numa_maps that gives more information
      about the vma's of a process.  numa_maps is indexes by the start address
      found in /proc/<pid>/maps.  F.e.  with this patch you can see the page use
      of the "getty" process:
      
      margin:/proc/12008 # cat maps
      00000000-00004000 r--p 00000000 00:00 0
      2000000000000000-200000000002c000 r-xp 00000000 08:04 516                /lib/ld-2.3.3.so
      2000000000038000-2000000000040000 rw-p 00028000 08:04 516                /lib/ld-2.3.3.so
      2000000000040000-2000000000044000 rw-p 2000000000040000 00:00 0
      2000000000058000-2000000000260000 r-xp 00000000 08:04 54707842           /lib/tls/libc.so.6.1
      2000000000260000-2000000000268000 ---p 00208000 08:04 54707842           /lib/tls/libc.so.6.1
      2000000000268000-2000000000274000 rw-p 00200000 08:04 54707842           /lib/tls/libc.so.6.1
      2000000000274000-2000000000280000 rw-p 2000000000274000 00:00 0
      2000000000280000-20000000002b4000 r--p 00000000 08:04 9126923            /usr/lib/locale/en_US.utf8/LC_CTYPE
      2000000000300000-2000000000308000 r--s 00000000 08:04 60071467           /usr/lib/gconv/gconv-modules.cache
      2000000000318000-2000000000328000 rw-p 2000000000318000 00:00 0
      4000000000000000-4000000000008000 r-xp 00000000 08:04 29576399           /sbin/mingetty
      6000000000004000-6000000000008000 rw-p 00004000 08:04 29576399           /sbin/mingetty
      6000000000008000-600000000002c000 rw-p 6000000000008000 00:00 0          [heap]
      60000fff7fffc000-60000fff80000000 rw-p 60000fff7fffc000 00:00 0
      60000ffffff44000-60000ffffff98000 rw-p 60000ffffff44000 00:00 0          [stack]
      a000000000000000-a000000000020000 ---p 00000000 00:00 0                  [vdso]
      
      cat numa_maps
      2000000000000000 default MaxRef=43 Pages=11 Mapped=11 N0=4 N1=3 N2=2 N3=2
      2000000000038000 default MaxRef=1 Pages=2 Mapped=2 Anon=2 N0=2
      2000000000040000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      2000000000058000 default MaxRef=43 Pages=61 Mapped=61 N0=14 N1=15 N2=16 N3=16
      2000000000268000 default MaxRef=1 Pages=2 Mapped=2 Anon=2 N0=2
      2000000000274000 default MaxRef=1 Pages=3 Mapped=3 Anon=3 N0=3
      2000000000280000 default MaxRef=8 Pages=3 Mapped=3 N0=3
      2000000000300000 default MaxRef=8 Pages=2 Mapped=2 N0=2
      2000000000318000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N2=1
      4000000000000000 default MaxRef=6 Pages=2 Mapped=2 N1=2
      6000000000004000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      6000000000008000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      60000fff7fffc000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      60000ffffff44000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      
      getty uses ld.so.  The first vma is the code segment which is used by 43
      other processes and the pages are evenly distributed over the 4 nodes.
      
      The second vma is the process specific data portion for ld.so.  This is
      only one page.
      
      The display format is:
      
      <startaddress>	 Links to information in /proc/<pid>/map
      <memory policy>  This can be "default" "interleave={}", "prefer=<node>" or "bind={<zones>}"
      MaxRef=		<maximum reference to a page in this vma>
      Pages=		<Nr of pages in use>
      Mapped=		<Nr of pages with mapcount >
      Anon=		<nr of anonymous pages>
      Nx=		<Nr of pages on Node x>
      
      The content of the proc-file is self-evident.  If this would be tied into
      the sparsemem system then the contents of this file would not be too
      useful.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6e21c8f1
  3. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4