1. 10 1月, 2006 1 次提交
  2. 09 1月, 2006 1 次提交
    • A
      [PATCH] drop-pagecache · 9d0243bc
      Andrew Morton 提交于
      Add /proc/sys/vm/drop_caches.  When written to, this will cause the kernel to
      discard as much pagecache and/or reclaimable slab objects as it can.  THis
      operation requires root permissions.
      
      It won't drop dirty data, so the user should run `sync' first.
      
      Caveats:
      
      a) Holds inode_lock for exorbitant amounts of time.
      
      b) Needs to be taught about NUMA nodes: propagate these all the way through
         so the discarding can be controlled on a per-node basis.
      
      This is a debugging feature: useful for getting consistent results between
      filesystem benchmarks.  We could possibly put it under a config option, but
      it's less than 300 bytes.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9d0243bc
  3. 10 9月, 2005 1 次提交
  4. 05 9月, 2005 1 次提交
    • M
      [PATCH] add /proc/pid/smaps · e070ad49
      Mauricio Lin 提交于
      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: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e070ad49
  5. 01 5月, 2005 1 次提交
  6. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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