1. 04 1月, 2014 1 次提交
  2. 07 11月, 2013 2 次提交
  3. 28 10月, 2013 1 次提交
  4. 31 8月, 2013 1 次提交
  5. 04 7月, 2013 1 次提交
  6. 30 4月, 2013 1 次提交
  7. 05 4月, 2013 3 次提交
    • A
      mtd: merge mtdchar module with mtdcore · 660685d9
      Artem Bityutskiy 提交于
      The MTD subsystem has historically tried to be as configurable as possible. The
      side-effect of this is that its configuration menu is rather large, and we are
      gradually shrinking it. For example, we recently merged partitions support with
      the mtdcore.
      
      This patch does the next step - it merges the mtdchar module to mtdcore. And in
      this case this is not only about eliminating too fine-grained separation and
      simplifying the configuration menu. This is also about eliminating seemingly
      useless kernel module.
      
      Indeed, mtdchar is a module that allows user-space making use of MTD devices
      via /dev/mtd* character devices. If users do not enable it, they simply cannot
      use MTD devices at all. They cannot read or write the flash contents. Is it a
      sane and useful setup? I believe not. And everyone just enables mtdchar.
      
      Having mtdchar separate is also a little bit harmful. People sometimes miss the
      fact that they need to enable an additional configuration option to have
      user-space MTD interfaces, and then they wonder why on earth the kernel does
      not allow using the flash? They spend time asking around.
      
      Thus, let's just get rid of this module and make it part of mtd core.
      
      Note, mtdchar had additional configuration option to enable OTP interfaces,
      which are present on some flashes. I removed that option as well - it saves a
      really tiny amount space.
      
      [dwmw2: Strictly speaking, you can mount file systems on MTD devices just
              fine without the mtdchar (or mtdblock) devices; you just can't do
              other manipulations directly on the underlying device. But still I
              agree that it makes sense to make this unconditional. And Yay! we
              get to kill off an instance of checking CONFIG_foo_MODULE, which is
              an abomination that should never happen.]
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      660685d9
    • A
      mtd: mtdcore: remove few useless #ifdef's · 93e56214
      Artem Bityutskiy 提交于
      Remove a couple of useles '#ifdef CONFIG_PROC_FS's around procfs functions
      which anyway turn into empty function in 'proc_fs.h' file when CONFIG_PROC_FS
      is not defined.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      93e56214
    • A
      mtd: add 'const' qualifier to a couple of register functions · 26a47346
      Artem Bityutskiy 提交于
      'mtd_device_parse_register()' and 'parse_mtd_partitions()' functions accept a
      an array of character pointers. These functions modify neither the pointers nor
      the characters they point to. The characters are actually names of the MTD
      parsers.
      
      At the moment, the argument type is 'const char **', which means that only the
      names of the parsers are constant. Let's turn the argument type into 'const
      char * const *', which means that both names and the pointers which point to
      them are constant.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      26a47346
  8. 28 2月, 2013 1 次提交
  9. 11 12月, 2012 1 次提交
    • L
      Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage · caf49191
      Linus Torvalds 提交于
      This reverts commits a5091539 and
      d7c3b937.
      
      This is a revert of a revert of a revert.  In addition, it reverts the
      even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
      original commits in linux-next.
      
      It turns out that the original patch really was bogus, and that the
      original revert was the correct thing to do after all.  We thought we
      had fixed the problem, and then reverted the revert, but the problem
      really is fundamental: waking up kswapd simply isn't the right thing to
      do, and direct reclaim sometimes simply _is_ the right thing to do.
      
      When certain allocations fail, we simply should try some direct reclaim,
      and if that fails, fail the allocation.  That's the right thing to do
      for THP allocations, which can easily fail, and the GPU allocations want
      to do that too.
      
      So starting kswapd is sometimes simply wrong, and removing the flag that
      said "don't start kswapd" was a mistake.  Let's hope we never revisit
      this mistake again - and certainly not this many times ;)
      Acked-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      caf49191
  10. 01 12月, 2012 1 次提交
    • A
      revert "Revert "mm: remove __GFP_NO_KSWAPD"" · a5091539
      Andrew Morton 提交于
      It apepars that this patch was innocent, and we hope that "mm: avoid
      waking kswapd for THP allocations when compaction is deferred or
      contended" will fix the final kswapd-spinning cause.
      
      Cc: Zdenek Kabelac <zkabelac@redhat.com>
      Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
      Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Cc: Jiri Slaby <jirislaby@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a5091539
  11. 27 11月, 2012 1 次提交
    • M
      Revert "mm: remove __GFP_NO_KSWAPD" · 82b212f4
      Mel Gorman 提交于
      With "mm: vmscan: scale number of pages reclaimed by reclaim/compaction
      based on failures" reverted, Zdenek Kabelac reported the following
      
        Hmm,  so it's just took longer to hit the problem and observe
        kswapd0 spinning on my CPU again - it's not as endless like before -
        but still it easily eats minutes - it helps to	turn off  Firefox
        or TB  (memory hungry apps) so kswapd0 stops soon - and restart
        those apps again.  (And I still have like >1GB of cached memory)
      
        kswapd0         R  running task        0    30      2 0x00000000
        Call Trace:
          preempt_schedule+0x42/0x60
          _raw_spin_unlock+0x55/0x60
          put_super+0x31/0x40
          drop_super+0x22/0x30
          prune_super+0x149/0x1b0
          shrink_slab+0xba/0x510
      
      The sysrq+m indicates the system has no swap so it'll never reclaim
      anonymous pages as part of reclaim/compaction.  That is one part of the
      problem but not the root cause as file-backed pages could also be
      reclaimed.
      
      The likely underlying problem is that kswapd is woken up or kept awake
      for each THP allocation request in the page allocator slow path.
      
      If compaction fails for the requesting process then compaction will be
      deferred for a time and direct reclaim is avoided.  However, if there
      are a storm of THP requests that are simply rejected, it will still be
      the the case that kswapd is awake for a prolonged period of time as
      pgdat->kswapd_max_order is updated each time.  This is noticed by the
      main kswapd() loop and it will not call kswapd_try_to_sleep().  Instead
      it will loopp, shrinking a small number of pages and calling
      shrink_slab() on each iteration.
      
      The temptation is to supply a patch that checks if kswapd was woken for
      THP and if so ignore pgdat->kswapd_max_order but it'll be a hack and not
      backed up by proper testing.  As 3.7 is very close to release and this
      is not a bug we should release with, a safer path is to revert "mm:
      remove __GFP_NO_KSWAPD" for now and revisit it with the view to ironing
      out the balance_pgdat() logic in general.
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Cc: Zdenek Kabelac <zkabelac@redhat.com>
      Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
      Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Cc: Jiri Slaby <jirislaby@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      82b212f4
  12. 09 10月, 2012 1 次提交
  13. 29 9月, 2012 1 次提交
  14. 07 7月, 2012 1 次提交
  15. 14 5月, 2012 3 次提交
  16. 27 3月, 2012 10 次提交
  17. 30 1月, 2012 1 次提交
  18. 10 1月, 2012 9 次提交