1. 30 Nov, 2012 9 commits
  2. 23 Nov, 2012 20 commits
  3. 22 Nov, 2012 9 commits
  4. 21 Nov, 2012 2 commits
    • Alex Deucher's avatar
      drm/radeon: add new SI pci id · 0181bd5d
      Alex Deucher authored
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      0181bd5d
    • Dave Hansen's avatar
      fix incorrect NR_FREE_PAGES accounting (appears like memory leak) · ef6c5be6
      Dave Hansen authored
      There have been some 3.7-rc reports of vm issues, including some kswapd
      bugs and, more importantly, some memory "leaks":
      
      	http://www.spinics.net/lists/linux-mm/msg46187.html
      	https://bugzilla.kernel.org/show_bug.cgi?id=50181
      
      Commit 1fb3f8ca ("mm: compaction: capture a suitable high-order page
      immediately when it is made available") took split_free_page() and
      reused it for the compaction code.  It does something curious with
      capture_free_page() (previously known as split_free_page()):
      
        int capture_free_page(struct page *page, int alloc_order,
        ...
                __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
      
        -       /* Split into individual pages */
        -       set_page_refcounted(page);
        -       split_page(page, order);
        +       if (alloc_order != order)
        +               expand(zone, page, alloc_order, order,
        +                       &zone->free_area[order], migratetype);
      
      Note that expand() puts the pages _back_ in the allocator, but it does
      not bump NR_FREE_PAGES.  We "return" 'alloc_order' worth of pages, but
      we accounted for removing 'order' in the __mod_zone_page_state() call.
      
      For the old split_page()-style use (order==alloc_order) the bug will not
      trigger.  But, when called from the compaction code where we
      occasionally get a larger page out of the buddy allocator than we need,
      we will run in to this.
      
      This patch simply changes the NR_FREE_PAGES manipulation to the correct
      'alloc_order' instead of 'order'.
      
      I've been able to repeatedly trigger this in my testing environment.
      The amount "leaked" very closely tracks the imbalance I see in buddy
      pages vs.  NR_FREE_PAGES.  I have confirmed that this patch fixes the
      imbalance
      Signed-off-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ef6c5be6