1. 28 6月, 2006 1 次提交
  2. 23 6月, 2006 4 次提交
    • A
      [PATCH] initialise total_memory() earlier · bd1e22b8
      Andrew Morton 提交于
      Initialise total_memory earlier in boot.  Because if for some reason we run
      page reclaim early in boot, we don't want total_memory to be zero when we use
      it as a divisor.
      
      And rename total_memory to vm_total_pages to avoid naming clashes with
      architectures.
      
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Martin Bligh <mbligh@google.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bd1e22b8
    • C
      [PATCH] More page migration: use migration entries for file pages · 04e62a29
      Christoph Lameter 提交于
      This implements the use of migration entries to preserve ptes of file backed
      pages during migration.  Processes can therefore be migrated back and forth
      without loosing their connection to pagecache pages.
      
      Note that we implement the migration entries only for linear mappings.
      Nonlinear mappings still require the unmapping of the ptes for migration.
      
      And another writepage() ugliness shows up.  writepage() can drop the page
      lock.  Therefore we have to remove migration ptes before calling writepages()
      in order to avoid having migration entries point to unlocked pages.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      04e62a29
    • O
      [PATCH] writeback: fix range handling · 111ebb6e
      OGAWA Hirofumi 提交于
      When a writeback_control's `start' and `end' fields are used to
      indicate a one-byte-range starting at file offset zero, the required
      values of .start=0,.end=0 mean that the ->writepages() implementation
      has no way of telling that it is being asked to perform a range
      request.  Because we're currently overloading (start == 0 && end == 0)
      to mean "this is not a write-a-range request".
      
      To make all this sane, the patch changes range of writeback_control.
      
      So caller does: If it is calling ->writepages() to write pages, it
      sets range (range_start/end or range_cyclic) always.
      
      And if range_cyclic is true, ->writepages() thinks the range is
      cyclic, otherwise it just uses range_start and range_end.
      
      This patch does,
      
          - Add LLONG_MAX, LLONG_MIN, ULLONG_MAX to include/linux/kernel.h
            -1 is usually ok for range_end (type is long long). But, if someone did,
      
      		range_end += val;		range_end is "val - 1"
      		u64val = range_end >> bits;	u64val is "~(0ULL)"
      
            or something, they are wrong. So, this adds LLONG_MAX to avoid nasty
            things, and uses LLONG_MAX for range_end.
      
          - All callers of ->writepages() sets range_start/end or range_cyclic.
      
          - Fix updates of ->writeback_index. It seems already bit strange.
            If it starts at 0 and ended by check of nr_to_write, this last
            index may reduce chance to scan end of file.  So, this updates
            ->writeback_index only if range_cyclic is true or whole-file is
            scanned.
      Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Nathan Scott <nathans@sgi.com>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: "Vladimir V. Saveliev" <vs@namesys.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      111ebb6e
    • R
      [PATCH] swsusp: rework memory shrinker · d6277db4
      Rafael J. Wysocki 提交于
      Rework the swsusp's memory shrinker in the following way:
      
      - Simplify balance_pgdat() by removing all of the swsusp-related code
        from it.
      
      - Make shrink_all_memory() use shrink_slab() and a new function
        shrink_all_zones() which calls shrink_active_list() and
        shrink_inactive_list() directly for each zone in a way that's optimized
        for suspend.
      
      In shrink_all_memory() we try to free exactly as many pages as the caller
      asks for, preferably in one shot, starting from easier targets.   If slab
      caches are huge, they are most likely to have enough pages to reclaim.
       The inactive lists are next (the zones with more inactive pages go first)
      etc.
      
      Each time shrink_all_memory() attempts to shrink the active and inactive
      lists for each zone in 5 passes.   In the first pass, only the inactive
      lists are taken into consideration.   In the next two passes the active
      lists are also shrunk, but mapped pages are not reclaimed.   In the last
      two passes the active and inactive lists are shrunk and mapped pages are
      reclaimed as well.  The aim of this is to alter the reclaim logic to choose
      the best pages to keep on resume and improve the responsiveness of the
      resumed system.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NCon Kolivas <kernel@kolivas.org>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d6277db4
  3. 12 6月, 2006 1 次提交
  4. 26 4月, 2006 1 次提交
  5. 28 3月, 2006 1 次提交
  6. 26 3月, 2006 1 次提交
    • A
      [PATCH] find_task_by_pid() needs tasklist_lock · 05eeae20
      Andrew Morton 提交于
      A couple of places are forgetting to take it.
      
      The kswapd case is probably unimportant.  keventd_create_kthread() was racy.
      
      The whole thing is a bit flakey: you start a kernel thread, get its pid from
      kernel_thread() then look up its task_struct.
      
      a) It assumes that pid recycling takes a "long" time.
      
      b) We get a task_struct but no reference was taken on it.  The owner of the
         kswapd and kthread task_struct*'s must assume that the new thread won't
         exit unexpectedly.  Because if it does, they're left holding dead memory
         and any attempt to control or stop that task will crash.
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      05eeae20
  7. 22 3月, 2006 16 次提交
  8. 15 3月, 2006 1 次提交
  9. 10 3月, 2006 1 次提交
  10. 25 2月, 2006 1 次提交
  11. 12 2月, 2006 3 次提交
  12. 11 2月, 2006 1 次提交
  13. 02 2月, 2006 8 次提交