1. 07 11月, 2015 1 次提交
    • M
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman 提交于
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      reserves.
      
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      
      This patch then converts a number of sites
      
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: NMel Gorman <mgorman@techsingularity.net>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0164adc
  2. 25 10月, 2015 1 次提交
    • D
      iommu/vt-d: Clean up pasid_enabled() and ecs_enabled() dependencies · d42fde70
      David Woodhouse 提交于
      When booted with intel_iommu=ecs_off we were still allocating the PASID
      tables even though we couldn't actually use them. We really want to make
      the pasid_enabled() macro depend on ecs_enabled().
      
      Which is unfortunate, because currently they're the other way round to
      cope with the Broadwell/Skylake problems with ECS.
      
      Instead of having ecs_enabled() depend on pasid_enabled(), which was never
      something that made me happy anyway, make it depend in the normal case
      on the "broken PASID" bit 28 *not* being set.
      
      Then pasid_enabled() can depend on ecs_enabled() as it should. And we also
      don't need to mess with it if we ever see an implementation that has some
      features requiring ECS (like PRI) but which *doesn't* have PASID support.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      d42fde70
  3. 22 10月, 2015 1 次提交
  4. 19 10月, 2015 1 次提交
  5. 15 10月, 2015 7 次提交
  6. 14 10月, 2015 2 次提交
    • D
      iommu/vt-d: Switch from ioremap_cache to memremap · dfddb969
      Dan Williams 提交于
      In preparation for deprecating ioremap_cache() convert its usage in
      intel-iommu to memremap.  This also eliminates the mishandling of the
      __iomem annotation in the implementation.
      
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      dfddb969
    • C
      iommu/vt-d: fix range computation when making room for large pages · ba2374fd
      Christian Zander 提交于
      In preparation for the installation of a large page, any small page
      tables that may still exist in the target IOV address range are
      removed.  However, if a scatter/gather list entry is large enough to
      fit more than one large page, the address space for any subsequent
      large pages is not cleared of conflicting small page tables.
      
      This can cause legitimate mapping requests to fail with errors of the
      form below, potentially followed by a series of IOMMU faults:
      
      ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083)
      
      In this example, a 4MiB scatter/gather list entry resulted in the
      successful installation of a large page @ vPFN 0xfdc00, followed by
      a failed attempt to install another large page @ vPFN 0xfde00, due to
      the presence of a pointer to a small page table @ 0x7f83a4000.
      
      To address this problem, compute the number of large pages that fit
      into a given scatter/gather list entry, and use it to derive the
      last vPFN covered by the large page(s).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NChristian Zander <christian@nervanasys.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      ba2374fd
  7. 05 10月, 2015 2 次提交
  8. 04 10月, 2015 1 次提交
  9. 29 9月, 2015 1 次提交
  10. 25 8月, 2015 1 次提交
  11. 17 8月, 2015 1 次提交
    • D
      scatterlist: use sg_phys() · db0fa0cb
      Dan Williams 提交于
      Coccinelle cleanup to replace open coded sg to physical address
      translations.  This is in preparation for introducing scatterlists that
      reference __pfn_t.
      
      // sg_phys.cocci: convert usage page_to_phys(sg_page(sg)) to sg_phys(sg)
      // usage: make coccicheck COCCI=sg_phys.cocci MODE=patch
      
      virtual patch
      
      @@
      struct scatterlist *sg;
      @@
      
      - page_to_phys(sg_page(sg)) + sg->offset
      + sg_phys(sg)
      
      @@
      struct scatterlist *sg;
      @@
      
      - page_to_phys(sg_page(sg))
      + sg_phys(sg) & PAGE_MASK
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      db0fa0cb
  12. 14 8月, 2015 3 次提交
  13. 12 8月, 2015 18 次提交