1. 26 12月, 2016 2 次提交
    • N
      mm: add PageWaiters indicating tasks are waiting for a page bit · 62906027
      Nicholas Piggin 提交于
      Add a new page flag, PageWaiters, to indicate the page waitqueue has
      tasks waiting. This can be tested rather than testing waitqueue_active
      which requires another cacheline load.
      
      This bit is always set when the page has tasks on page_waitqueue(page),
      and is set and cleared under the waitqueue lock. It may be set when
      there are no tasks on the waitqueue, which will cause a harmless extra
      wakeup check that will clears the bit.
      
      The generic bit-waitqueue infrastructure is no longer used for pages.
      Instead, waitqueues are used directly with a custom key type. The
      generic code was not flexible enough to have PageWaiters manipulation
      under the waitqueue lock (which simplifies concurrency).
      
      This improves the performance of page lock intensive microbenchmarks by
      2-3%.
      
      Putting two bits in the same word opens the opportunity to remove the
      memory barrier between clearing the lock bit and testing the waiters
      bit, after some work on the arch primitives (e.g., ensuring memory
      operand widths match and cover both bits).
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Bob Peterson <rpeterso@redhat.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Andrew Lutomirski <luto@kernel.org>
      Cc: Andreas Gruenbacher <agruenba@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      62906027
    • N
      mm: Use owner_priv bit for PageSwapCache, valid when PageSwapBacked · 6326fec1
      Nicholas Piggin 提交于
      A page is not added to the swap cache without being swap backed,
      so PageSwapBacked mappings can use PG_owner_priv_1 for PageSwapCache.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Acked-by: NHugh Dickins <hughd@google.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Bob Peterson <rpeterso@redhat.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Andrew Lutomirski <luto@kernel.org>
      Cc: Andreas Gruenbacher <agruenba@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6326fec1
  2. 25 12月, 2016 1 次提交
  3. 21 12月, 2016 1 次提交
    • J
      mm: fadvise: avoid expensive remote LRU cache draining after FADV_DONTNEED · 4dd72b4a
      Johannes Weiner 提交于
      When FADV_DONTNEED cannot drop all pages in the range, it observes that
      some pages might still be on per-cpu LRU caches after recent
      instantiation and so initiates remote calls to all CPUs to flush their
      local caches.  However, in most cases, the fadvise happens from the same
      context that instantiated the pages, and any pre-LRU pages in the
      specified range are most likely sitting on the local CPU's LRU cache,
      and so in many cases this results in unnecessary remote calls, which, in
      a loaded system, can hold up the fadvise() call significantly.
      
      [ I didn't record it in the extreme case we observed at Facebook,
        unfortunately. We had a slow-to-respond system and noticed it
        lru_add_drain_all() leading the profile during fadvise calls. This
        patch came out of thinking about the code and how we commonly call
        FADV_DONTNEED.
      
        FWIW, I wrote a silly directory tree walker/searcher that recurses
        through /usr to read and FADV_DONTNEED each file it finds. On a 2
        socket 40 ht machine, over 1% is spent in lru_add_drain_all(). With
        the patch, that cost is gone; the local drain cost shows at 0.09%. ]
      
      Try to avoid the remote call by flushing the local LRU cache before even
      attempting to invalidate anything.  It's a cheap operation, and the
      local LRU cache is the most likely to hold any pre-LRU pages in the
      specified fadvise range.
      
      Link: http://lkml.kernel.org/r/20161214210017.GA1465@cmpxchg.orgSigned-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NHillf Danton <hillf.zj@alibaba-inc.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4dd72b4a
  4. 15 12月, 2016 26 次提交
  5. 13 12月, 2016 10 次提交