1. 02 3月, 2010 1 次提交
  2. 05 2月, 2010 35 次提交
  3. 30 1月, 2010 4 次提交
    • L
      Linux 2.6.33-rc6 · abe94c75
      Linus Torvalds 提交于
      abe94c75
    • D
      mfd: Fix asic3 build · 4995c0b3
      Dmitry Artamonow 提交于
      asic3 also needs tmio_core or otherwise will fail to build.
      Signed-off-by: NDmitry Artamonow <mad_soft@inbox.ru>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      4995c0b3
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · 499a2673
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: update multi-touch protocol documentation
        Input: add the ABS_MT_PRESSURE event
        Input: winbond-cir - remove dmesg spam
        Input: lifebook - add another Lifebook DMI signature
        Input: ad7879 - support auxiliary GPIOs via gpiolib
      499a2673
    • H
      mm: fix migratetype bug which slowed swapping · a7016235
      Hugh Dickins 提交于
      After memory pressure has forced it to dip into the reserves, 2.6.32's
      5f8dcc21 "page-allocator: split per-cpu
      list into one-list-per-migrate-type" has been returning MIGRATE_RESERVE
      pages to the MIGRATE_MOVABLE free_list: in some sense depleting reserves.
      
      Fix that in the most straightforward way (which, considering the overheads
      of alternative approaches, is Mel's preference): the right migratetype is
      already in page_private(page), but free_pcppages_bulk() wasn't using it.
      
      How did this bug show up?  As a 20% slowdown in my tmpfs loop kbuild
      swapping tests, on PowerMac G5 with SLUB allocator.  Bisecting to that
      commit was easy, but explaining the magnitude of the slowdown not easy.
      
      The same effect appears, but much less markedly, with SLAB, and even
      less markedly on other machines (the PowerMac divides into fewer zones
      than x86, I think that may be a factor).  We guess that lumpy reclaim
      of short-lived high-order pages is implicated in some way, and probably
      this bug has been tickling a poor decision somewhere in page reclaim.
      
      But instrumentation hasn't told me much, I've run out of time and
      imagination to determine exactly what's going on, and shouldn't hold up
      the fix any longer: it's valid, and might even fix other misbehaviours.
      Signed-off-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
      Acked-by: NMel Gorman <mel@csn.ul.ie>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7016235