1. 18 10月, 2013 3 次提交
    • C
      KVM: ARM: Support hugetlbfs backed huge pages · ad361f09
      Christoffer Dall 提交于
      Support huge pages in KVM/ARM and KVM/ARM64.  The pud_huge checking on
      the unmap path may feel a bit silly as the pud_huge check is always
      defined to false, but the compiler should be smart about this.
      
      Note: This deals only with VMAs marked as huge which are allocated by
      users through hugetlbfs only.  Transparent huge pages can only be
      detected by looking at the underlying pages (or the page tables
      themselves) and this patch so far simply maps these on a page-by-page
      level in the Stage-2 page tables.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      ad361f09
    • C
      KVM: ARM: Update comments for kvm_handle_wfi · 86ed81aa
      Christoffer Dall 提交于
      Update comments to reflect what is really going on and add the TWE bit
      to the comments in kvm_arm.h.
      
      Also renames the function to kvm_handle_wfx like is done on arm64 for
      consistency and uber-correctness.
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      86ed81aa
    • M
      ARM: KVM: Yield CPU when vcpu executes a WFE · 58d5ec8f
      Marc Zyngier 提交于
      On an (even slightly) oversubscribed system, spinlocks are quickly
      becoming a bottleneck, as some vcpus are spinning, waiting for a
      lock to be released, while the vcpu holding the lock may not be
      running at all.
      
      This creates contention, and the observed slowdown is 40x for
      hackbench. No, this isn't a typo.
      
      The solution is to trap blocking WFEs and tell KVM that we're
      now spinning. This ensures that other vpus will get a scheduling
      boost, allowing the lock to be released more quickly. Also, using
      CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
      when the VM is severely overcommited.
      
      Quick test to estimate the performance: hackbench 1 process 1000
      
      2xA15 host (baseline):	1.843s
      
      2xA15 guest w/o patch:	2.083s
      4xA15 guest w/o patch:	80.212s
      8xA15 guest w/o patch:	Could not be bothered to find out
      
      2xA15 guest w/ patch:	2.102s
      4xA15 guest w/ patch:	3.205s
      8xA15 guest w/ patch:	6.887s
      
      So we go from a 40x degradation to 1.5x in the 2x overcommit case,
      which is vaguely more acceptable.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      58d5ec8f
  2. 16 10月, 2013 2 次提交
    • C
      KVM: ARM: Update comments for kvm_handle_wfi · 82ea046c
      Christoffer Dall 提交于
      Update comments to reflect what is really going on and add the TWE bit
      to the comments in kvm_arm.h.
      
      Also renames the function to kvm_handle_wfx like is done on arm64 for
      consistency and uber-correctness.
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      82ea046c
    • M
      ARM: KVM: Yield CPU when vcpu executes a WFE · 1f558098
      Marc Zyngier 提交于
      On an (even slightly) oversubscribed system, spinlocks are quickly
      becoming a bottleneck, as some vcpus are spinning, waiting for a
      lock to be released, while the vcpu holding the lock may not be
      running at all.
      
      This creates contention, and the observed slowdown is 40x for
      hackbench. No, this isn't a typo.
      
      The solution is to trap blocking WFEs and tell KVM that we're
      now spinning. This ensures that other vpus will get a scheduling
      boost, allowing the lock to be released more quickly. Also, using
      CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
      when the VM is severely overcommited.
      
      Quick test to estimate the performance: hackbench 1 process 1000
      
      2xA15 host (baseline):	1.843s
      
      2xA15 guest w/o patch:	2.083s
      4xA15 guest w/o patch:	80.212s
      8xA15 guest w/o patch:	Could not be bothered to find out
      
      2xA15 guest w/ patch:	2.102s
      4xA15 guest w/ patch:	3.205s
      8xA15 guest w/ patch:	6.887s
      
      So we go from a 40x degradation to 1.5x in the 2x overcommit case,
      which is vaguely more acceptable.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      1f558098
  3. 14 10月, 2013 1 次提交
  4. 13 10月, 2013 2 次提交
  5. 03 10月, 2013 1 次提交
  6. 02 9月, 2013 3 次提交
  7. 31 8月, 2013 1 次提交
  8. 27 8月, 2013 1 次提交
  9. 26 8月, 2013 7 次提交
  10. 23 8月, 2013 1 次提交
  11. 20 8月, 2013 2 次提交
    • W
      ARM: cacheflush: don't round address range up to nearest page · d9524dc3
      Will Deacon 提交于
      The flush_cache_user_range macro takes a pair of addresses describing
      the start and end of the virtual address range to flush. Due to an
      accidental oversight when flush_cache_range_user was introduced, the
      address range was rounded up so that the start and end addresses were
      page-aligned.
      
      For historical reference, the interesting commits in history.git are:
      
      10eacf1775e1 ("[ARM] Clean up ARM cache handling interfaces (part 1)")
      71432e79b76b ("[ARM] Add flush_cache_user_page() for sys_cacheflush()")
      
      This patch removes the alignment code, reducing the amount of flushing
      required for ranges that are not an exact multiple of PAGE_SIZE.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NJonathan Austin <jonathan.austin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d9524dc3
    • W
      ARM: cacheflush: split user cache-flushing into interruptible chunks · 28256d61
      Will Deacon 提交于
      Flushing a large, non-faulting VMA from userspace can potentially result
      in a long time spent flushing the cache line-by-line without preemption
      occurring (in the case of CONFIG_PREEMPT=n).
      
      Whilst this doesn't affect the stability of the system, it can certainly
      affect the responsiveness and CPU availability for other tasks.
      
      This patch splits up the user cacheflush code so that it flushes in
      chunks of a page. After each chunk has been flushed, we may reschedule
      if appropriate and, before processing the next chunk, we allow any
      pending signals to be handled before resuming from where we left off.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      28256d61
  12. 16 8月, 2013 1 次提交
    • L
      Fix TLB gather virtual address range invalidation corner cases · 2b047252
      Linus Torvalds 提交于
      Ben Tebulin reported:
      
       "Since v3.7.2 on two independent machines a very specific Git
        repository fails in 9/10 cases on git-fsck due to an SHA1/memory
        failures.  This only occurs on a very specific repository and can be
        reproduced stably on two independent laptops.  Git mailing list ran
        out of ideas and for me this looks like some very exotic kernel issue"
      
      and bisected the failure to the backport of commit 53a59fc6 ("mm:
      limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT").
      
      That commit itself is not actually buggy, but what it does is to make it
      much more likely to hit the partial TLB invalidation case, since it
      introduces a new case in tlb_next_batch() that previously only ever
      happened when running out of memory.
      
      The real bug is that the TLB gather virtual memory range setup is subtly
      buggered.  It was introduced in commit 597e1c35 ("mm/mmu_gather:
      enable tlb flush range in generic mmu_gather"), and the range handling
      was already fixed at least once in commit e6c495a9 ("mm: fix the TLB
      range flushed when __tlb_remove_page() runs out of slots"), but that fix
      was not complete.
      
      The problem with the TLB gather virtual address range is that it isn't
      set up by the initial tlb_gather_mmu() initialization (which didn't get
      the TLB range information), but it is set up ad-hoc later by the
      functions that actually flush the TLB.  And so any such case that forgot
      to update the TLB range entries would potentially miss TLB invalidates.
      
      Rather than try to figure out exactly which particular ad-hoc range
      setup was missing (I personally suspect it's the hugetlb case in
      zap_huge_pmd(), which didn't have the same logic as zap_pte_range()
      did), this patch just gets rid of the problem at the source: make the
      TLB range information available to tlb_gather_mmu(), and initialize it
      when initializing all the other tlb gather fields.
      
      This makes the patch larger, but conceptually much simpler.  And the end
      result is much more understandable; even if you want to play games with
      partial ranges when invalidating the TLB contents in chunks, now the
      range information is always there, and anybody who doesn't want to
      bother with it won't introduce subtle bugs.
      
      Ben verified that this fixes his problem.
      Reported-bisected-and-tested-by: NBen Tebulin <tebulin@googlemail.com>
      Build-testing-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Build-testing-by: NRichard Weinberger <richard.weinberger@gmail.com>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b047252
  13. 14 8月, 2013 5 次提交
  14. 12 8月, 2013 8 次提交
  15. 03 8月, 2013 1 次提交
  16. 01 8月, 2013 1 次提交