1. 15 9月, 2008 1 次提交
  2. 22 8月, 2008 2 次提交
  3. 21 8月, 2008 4 次提交
  4. 20 8月, 2008 1 次提交
  5. 16 8月, 2008 2 次提交
    • M
      x86: fix section mismatch warning - spp_getpage() · 8d6ea967
      Marcin Slusarz 提交于
      WARNING: vmlinux.o(.text+0x17a3e): Section mismatch in reference from the function set_pte_vaddr_pud() to the function .init.text:spp_getpage()
      The function set_pte_vaddr_pud() references
      the function __init spp_getpage().
      This is often because set_pte_vaddr_pud lacks a __init
      annotation or the annotation of spp_getpage is wrong.
      
      spp_getpage is called from __init (__init_extra_mapping) and
      non __init (set_pte_vaddr_pud) functions, so it can't be __init.
      Unfortunately it calls alloc_bootmem_pages which is __init,
      but does it only when bootmem allocator is available (after_bootmem == 0).
      
      So annotate it accordingly.
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: H. Peter Anvin <hpa@zytor.com>
      8d6ea967
    • A
      x86: Fix ioremap off by one BUG · e213e877
      Andi Kleen 提交于
      Jean Delvare's machine triggered this BUG
      
      acpi_os_map_memory phys ffff0000 size 65535
      ------------[ cut here ]------------
      kernel BUG at arch/x86/mm/pat.c:233!
      
      with ACPI in the backtrace.
      
      Adding some debugging output showed that ACPI calls
      
      acpi_os_map_memory phys ffff0000 size 65535
      
      And ioremap/PAT does this check in 32bit, so addr+size wraps and the BUG
      in reserve_memtype() triggers incorrectly.
      
              BUG_ON(start >= end); /* end is exclusive */
      
      But reserve_memtype already uses u64:
      
      int reserve_memtype(u64 start, u64 end,
      
      so the 32bit truncation must happen in the caller. Presumably in ioremap
      when it passes this information to reserve_memtype().
      
      This patch does this computation in 64bit.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=11346Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      e213e877
  6. 15 8月, 2008 1 次提交
    • H
      x86: fix /proc/meminfo DirectMap · a06de630
      Hugh Dickins 提交于
      Do we actually want these DirectMap lines in the x86 /proc/meminfo?
      I can see they're interesting to CPA developers and TLB optimizers,
      but they don't fit its usual "where has all my memory gone?" usage.
      If they are to stay, here are some fixes.
      
      1. On x86_32 without PAE, they're not 2M but 4M pages: no need to
         mess with the internal enum, but show the right name to users.
      
      2. Many machines can never show anything but 0 for DirectMap1G,
         so suppress that line unless direct_gbpages are really enabled.
      
      3. The unit in /proc/meminfo is kB not number of pages: HugePages
         messed that up, but they're an example to regret not to follow.
      
      4. Once we use kB, it's easy to see that 1GB has gone missing (which
         explains why CONFIG_CPA_DEBUG=y soon wraps DirectMap2M negative):
         because head_64.S's level2_ident_pgt entries were not counted.
         My fix is not ideal, but works for more and for less than 1G,
         and avoids interfering with early bootup pagetable contortions.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a06de630
  7. 14 8月, 2008 2 次提交
  8. 12 8月, 2008 2 次提交
  9. 29 7月, 2008 1 次提交
  10. 27 7月, 2008 3 次提交
    • J
      x86: use generic show_mem() · 8dad322f
      Johannes Weiner 提交于
      Remove arch-specific show_mem() in favor of the generic version.
      
      This also removes the following redundant information display:
      
      	- pages in swapcache, printed by show_swap_cache_info()
      	- dirty pages, writeback pages, mapped pages, slab pages,
      	  pagetable pages, printed by show_free_areas()
      
      where show_mem() calls show_free_areas(), which calls
      show_swap_cache_info().
      Signed-off-by: NJohannes Weiner <hannes@saeurebad.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8dad322f
    • N
      x86: support 1GB hugepages with get_user_pages_lockless() · 652ea695
      Nick Piggin 提交于
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <andi@firstfloor.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      652ea695
    • N
      x86: lockless get_user_pages_fast() · 8174c430
      Nick Piggin 提交于
      Implement get_user_pages_fast without locking in the fastpath on x86.
      
      Do an optimistic lockless pagetable walk, without taking mmap_sem or any
      page table locks or even mmap_sem.  Page table existence is guaranteed by
      turning interrupts off (combined with the fact that we're always looking
      up the current mm, means we can do the lockless page table walk within the
      constraints of the TLB shootdown design).  Basically we can do this
      lockless pagetable walk in a similar manner to the way the CPU's pagetable
      walker does not have to take any locks to find present ptes.
      
      This patch (combined with the subsequent ones to convert direct IO to use
      it) was found to give about 10% performance improvement on a 2 socket 8
      core Intel Xeon system running an OLTP workload on DB2 v9.5
      
       "To test the effects of the patch, an OLTP workload was run on an IBM
        x3850 M2 server with 2 processors (quad-core Intel Xeon processors at
        2.93 GHz) using IBM DB2 v9.5 running Linux 2.6.24rc7 kernel.  Comparing
        runs with and without the patch resulted in an overall performance
        benefit of ~9.8%.  Correspondingly, oprofiles showed that samples from
        __up_read and __down_read routines that is seen during thread contention
        for system resources was reduced from 2.8% down to .05%.  Monitoring the
        /proc/vmstat output from the patched run showed that the counter for
        fast_gup contained a very high number while the fast_gup_slow value was
        zero."
      
      (fast_gup is the old name for get_user_pages_fast, fast_gup_slow is a
      counter we had for the number of times the slowpath was invoked).
      
      The main reason for the improvement is that DB2 has multiple threads each
      issuing direct-IO.  Direct-IO uses get_user_pages, and thus the threads
      contend the mmap_sem cacheline, and can also contend on page table locks.
      
      I would anticipate larger performance gains on larger systems, however I
      think DB2 uses an adaptive mix of threads and processes, so it could be
      that thread contention remains pretty constant as machine size increases.
      In which case, we stuck with "only" a 10% gain.
      
      The downside of using get_user_pages_fast is that if there is not a pte
      with the correct permissions for the access, we end up falling back to
      get_user_pages and so the get_user_pages_fast is a bit of extra work.
      However this should not be the common case in most performance critical
      code.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: Kconfig fix]
      [akpm@linux-foundation.org: Makefile fix/cleanup]
      [akpm@linux-foundation.org: warning fix]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Dave Kleikamp <shaggy@austin.ibm.com>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Dave Kleikamp <shaggy@austin.ibm.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Cc: Zach Brown <zach.brown@oracle.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Reviewed-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8174c430
  11. 25 7月, 2008 6 次提交
  12. 22 7月, 2008 3 次提交
  13. 20 7月, 2008 1 次提交
    • I
      Subject: devmem, x86: fix rename of CONFIG_NONPROMISC_DEVMEM · d092633b
      Ingo Molnar 提交于
      From: Arjan van de Ven <arjan@infradead.org>
      Date: Sat, 19 Jul 2008 15:47:17 -0700
      
      CONFIG_NONPROMISC_DEVMEM was a rather confusing name - but renaming it
      to CONFIG_PROMISC_DEVMEM causes problems on architectures that do not
      support this feature; this patch renames it to CONFIG_STRICT_DEVMEM,
      so that architectures can opt-in into it.
      
      ( the polarity of the option is still the same as it was originally; it
        needs to be for now to not break architectures that don't have the
        infastructure yet to support this feature)
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: "V.Radhakrishnan" <rk@atr-labs.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ---
      d092633b
  14. 19 7月, 2008 1 次提交
  15. 18 7月, 2008 3 次提交
  16. 17 7月, 2008 2 次提交
  17. 16 7月, 2008 1 次提交
  18. 13 7月, 2008 2 次提交
  19. 11 7月, 2008 2 次提交