1. 07 1月, 2009 6 次提交
  2. 13 11月, 2008 1 次提交
    • D
      cpusets: update mems allowed in page allocator · e33c3b5e
      David Rientjes 提交于
      If all allowable memory is unreclaimable, it is possible to loop forever
      in the page allocator for ~__GFP_NORETRY allocations.
      
      During this time, it is also possible for a task's cpuset to expand its
      set of allowable nodes so that it now includes free memory.  The cached
      copy of this set, current->mems_allowed, is stale, however, since there
      has not been a subsequent call to cpuset_update_task_memory_state().
      
      The cached copy of the set of allowable nodes is now updated in the page
      allocator's slow path so the additional memory is available to
      get_page_from_freelist().
      
      [akpm@linux-foundation.org: add comment]
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e33c3b5e
  3. 07 11月, 2008 1 次提交
  4. 20 10月, 2008 10 次提交
  5. 17 10月, 2008 1 次提交
  6. 03 10月, 2008 1 次提交
    • A
      mm: handle initialising compound pages at orders greater than MAX_ORDER · 6babc32c
      Andy Whitcroft 提交于
      When we initialise a compound page we initialise the page flags and head
      page pointer for all base pages spanned by that page.  When we initialise
      a gigantic page (a page of order greater than or equal to MAX_ORDER) we
      have to initialise more than MAX_ORDER_NR_PAGES pages.  Currently we
      assume that all elements of the mem_map in this page are contigious in
      memory.  However this is only guarenteed out to MAX_ORDER_NR_PAGES pages,
      and with SPARSEMEM enabled they will not be contigious.  This leads us to
      walk off the end of the first section and scribble on everything which
      follows, BAD.
      
      When we reach a MAX_ORDER_NR_PAGES boundary we much locate the next
      section of the mem_map.  As gigantic pages can only be maximally aligned
      we know this will occur at exact multiple of MAX_ORDER_NR_PAGES pages from
      the start of the page.
      
      This is a bug fix for the gigantic page support in hugetlbfs.
      
      Credit to Mel Gorman for spotting the issue.
      Signed-off-by: NAndy Whitcroft <apw@shadowen.org>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Jon Tollefson <kniht@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6babc32c
  7. 03 9月, 2008 2 次提交
  8. 13 8月, 2008 1 次提交
  9. 31 7月, 2008 1 次提交
  10. 28 7月, 2008 1 次提交
  11. 25 7月, 2008 12 次提交
  12. 08 7月, 2008 3 次提交
    • P
      mm, generic, x86 boot: more tweaks to hex prints of some pfn addresses · 5dab8ec1
      Paul Jackson 提交于
      Fix some problems with (and applies on top of) a previous patch:
        x86 boot: show pfn addresses in hex not decimal in some kernel info printks
      
      Primarily change "0x%8lx" format, which displays with a right aligned
      space filled hex number (spaces between the "0x" prefix and the number),
      into "%0#10lx" format, which zero fills instead of space fills, and
      which uses the printf flag '#' to request the "0x" prefix instead of
      hard coding it.
      
      Also replace some other "0x%lx" formats with "%#lx", making use of the
      '#' printf flag again.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
      Cc: "Jack Steiner" <steiner@sgi.com>
      Cc: "Mike Travis" <travis@sgi.com>
      Cc: "Huang
      Cc: Ying" <ying.huang@intel.com>
      Cc: "Andi Kleen" <andi@firstfloor.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5dab8ec1
    • P
      x86 boot: more consistently use type int for node ids · 2bc0d261
      Paul Jackson 提交于
      Everywhere I look, node id's are of type 'int', except in this one
      case, which has 'unsigned long'.  Change this one to 'int' as well.
      There is nothing special about the way this variable 'nid' is used in
      this routine to justify using an unusual type here.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
      Cc: "Jack Steiner" <steiner@sgi.com>
      Cc: "Mike Travis" <travis@sgi.com>
      Cc: "Huang
      Cc: Ying" <ying.huang@intel.com>
      Cc: "Andi Kleen" <andi@firstfloor.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2bc0d261
    • P
      x86 boot: show pfn addresses in hex not decimal in some kernel info printks · e2fc252e
      Paul Jackson 提交于
      Page frame numbers (the portion of physical addresses above the low
      order page offsets) are displayed in several kernel debug and info
      prints in decimal, not hex.  Decimal addresse are unreadable.  Use hex.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
      Cc: "Jack Steiner" <steiner@sgi.com>
      Cc: "Mike Travis" <travis@sgi.com>
      Cc: "Huang
      Cc: Ying" <ying.huang@intel.com>
      Cc: "Andi Kleen" <andi@firstfloor.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e2fc252e