1. 22 12月, 2009 1 次提交
    • A
      ACPI: processor: introduce arch_has_acpi_pdc · 1d9cb470
      Alex Chiang 提交于
      arch dependent helper function that tells us if we should attempt to
      evaluate _PDC on this machine or not.
      
      The x86 implementation assumes that the CPUs in the machine must be
      homogeneous, and that you cannot mix CPUs of different vendors.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1d9cb470
  2. 16 12月, 2009 4 次提交
  3. 15 12月, 2009 9 次提交
  4. 12 12月, 2009 2 次提交
  5. 09 12月, 2009 1 次提交
  6. 04 12月, 2009 1 次提交
  7. 03 12月, 2009 2 次提交
  8. 26 11月, 2009 1 次提交
    • I
      block: add helpers to run flush_dcache_page() against a bio and a request's pages · 2d4dc890
      Ilya Loginov 提交于
      Mtdblock driver doesn't call flush_dcache_page for pages in request.  So,
      this causes problems on architectures where the icache doesn't fill from
      the dcache or with dcache aliases.  The patch fixes this.
      
      The ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE symbol was introduced to avoid
      pointless empty cache-thrashing loops on architectures for which
      flush_dcache_page() is a no-op.  Every architecture was provided with this
      flush pages on architectires where ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE is
      equal 1 or do nothing otherwise.
      
      See "fix mtd_blkdevs problem with caches on some architectures" discussion
      on LKML for more information.
      Signed-off-by: NIlya Loginov <isloginov@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Peter Horton <phorton@bitbox.co.uk>
      Cc: "Ed L. Cashin" <ecashin@coraid.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2d4dc890
  9. 15 11月, 2009 1 次提交
  10. 07 11月, 2009 1 次提交
    • I
      ia64/xen: compilation fix · 5b5d9448
      Isaku Yamahata 提交于
      This patch fixes the following compilation error introduced by a PCI related
      features.
      
      The change set of 5dd1af9f84c79bedd589db89e71ca733f3bf0ebd moves some
      xen related definitions from the arch header file
      (x86/include/asm/xen/hypervisor.h) to the common header file
      (include/xen/xen.h).  So ia64/xen also follows it.
      
      In file included from linux-next/include/xen/grant_table.h:41,
                       from linux-next/drivers/block/xen-blkfront.c:48:
      linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: nested redefinition of 'enum xen_domain_type'
      linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: redeclaration of 'enum xen_domain_type'
      linux-next/arch/ia64/include/asm/xen/hypervisor.h:44: error: redeclaration of enumerator 'XEN_NATIVE'
      linux-next/include/xen/xen.h:5: error: previous definition of 'XEN_NATIVE' was here
      linux-next/arch/ia64/include/asm/xen/hypervisor.h:45: error: redeclaration of enumerator 'XEN_PV_DOMAIN'
      linux-next/include/xen/xen.h:6: error: previous definition of 'XEN_PV_DOMAIN' was here
      linux-next/arch/ia64/include/asm/xen/hypervisor.h:46: error: redeclaration of enumerator 'XEN_HVM_DOMAIN'
      linux-next/include/xen/xen.h:7: error: previous definition of 'XEN_HVM_DOMAIN' was here
      Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      5b5d9448
  11. 03 11月, 2009 1 次提交
    • T
      Revert "[IA64] fix percpu warnings" · e8c93fc7
      Tony Luck 提交于
      This reverts commit b94b0808.
      
      genksyms currently cannot handle complicated types for exported
      percpu variables.  Drop this patch for now as it prevents a
      module from being loaded on sn2 systems:
      
       xpc: no symbol version for per_cpu____sn_cnodeid_to_nasid
       xpc: Unknown symbol per_cpu____sn_cnodeid_to_nasid
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e8c93fc7
  12. 29 10月, 2009 1 次提交
    • T
      percpu: make percpu symbols in ia64 unique · 877105cc
      Tejun Heo 提交于
      This patch updates percpu related symbols in ia64 such that percpu
      symbols are unique and don't clash with local symbols.  This serves
      two purposes of decreasing the possibility of global percpu symbol
      collision and allowing dropping per_cpu__ prefix from percpu symbols.
      
      * arch/ia64/kernel/setup.c: s/cpu_info/ia64_cpu_info/
      
      Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
      which cause name clashes" patch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      877105cc
  13. 16 10月, 2009 1 次提交
  14. 15 10月, 2009 1 次提交
  15. 14 10月, 2009 1 次提交
  16. 13 10月, 2009 1 次提交
    • N
      net: Generalize socket rx gap / receive queue overflow cmsg · 3b885787
      Neil Horman 提交于
      Create a new socket level option to report number of queue overflows
      
      Recently I augmented the AF_PACKET protocol to report the number of frames lost
      on the socket receive queue between any two enqueued frames.  This value was
      exported via a SOL_PACKET level cmsg.  AFter I completed that work it was
      requested that this feature be generalized so that any datagram oriented socket
      could make use of this option.  As such I've created this patch, It creates a
      new SOL_SOCKET level option called SO_RXQ_OVFL, which when enabled exports a
      SOL_SOCKET level cmsg that reports the nubmer of times the sk_receive_queue
      overflowed between any two given frames.  It also augments the AF_PACKET
      protocol to take advantage of this new feature (as it previously did not touch
      sk->sk_drops, which this patch uses to record the overflow count).  Tested
      successfully by me.
      
      Notes:
      
      1) Unlike my previous patch, this patch simply records the sk_drops value, which
      is not a number of drops between packets, but rather a total number of drops.
      Deltas must be computed in user space.
      
      2) While this patch currently works with datagram oriented protocols, it will
      also be accepted by non-datagram oriented protocols. I'm not sure if thats
      agreeable to everyone, but my argument in favor of doing so is that, for those
      protocols which aren't applicable to this option, sk_drops will always be zero,
      and reporting no drops on a receive queue that isn't used for those
      non-participating protocols seems reasonable to me.  This also saves us having
      to code in a per-protocol opt in mechanism.
      
      3) This applies cleanly to net-next assuming that commit
      97775007 (my af packet cmsg patch) is reverted
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b885787
  17. 08 10月, 2009 1 次提交
    • T
      [IA64] Squeeze ticket locks back into 4 bytes. · 9d40ee20
      Tony Luck 提交于
      Linus pointed out that other people have spent large amounts of time
      and effort to optimize the layout of frequently used structures. Often
      these have embedded locks, and the assumption is that a lock takes
      4 bytes.  Linus also pointed out how to work with the limited options
      for atomic instructions on Itanium.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      9d40ee20
  18. 02 10月, 2009 1 次提交
    • T
      ia64: don't alias VMALLOC_END to vmalloc_end · 126b3fcd
      Tejun Heo 提交于
      If CONFIG_VIRTUAL_MEM_MAP is enabled, ia64 defines macro VMALLOC_END
      as unsigned long variable vmalloc_end which is adjusted to prepare
      room for vmemmap.  This becomes probnlematic if a local variables
      vmalloc_end is defined in some function (not very unlikely) and
      VMALLOC_END is used in the function - the function thinks its
      referencing the global VMALLOC_END value but would be referencing its
      own local vmalloc_end variable.
      
      There's no reason VMALLOC_END should be a macro.  Just define it as an
      unsigned long variable if CONFIG_VIRTUAL_MEM_MAP is set to avoid nasty
      surprises.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      126b3fcd
  19. 27 9月, 2009 1 次提交
  20. 25 9月, 2009 1 次提交
    • T
      [IA64] implement ticket locks for Itanium · 2c86963b
      Tony Luck 提交于
      Back in January 2008 Nick Piggin implemented "ticket" spinlocks
      for X86 (See commit 314cdbef).
      
      IA64 implementation has a couple of differences because of the
      available atomic operations ... e.g. we have no fetchadd2 instruction
      that operates on a 16-bit quantity so we make ticket locks use
      a 32-bit word for each of the current ticket and now-serving values.
      
      Performance on uncontended locks is about 8% worse than the previous
      implementation, but this seems a good trade for determinism in the
      contended case. Performance impact on macro-level benchmarks is in
      the noise.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      2c86963b
  21. 24 9月, 2009 3 次提交
  22. 22 9月, 2009 2 次提交
  23. 16 9月, 2009 1 次提交
    • P
      sched: Disable wakeup balancing · 182a85f8
      Peter Zijlstra 提交于
      Sysbench thinks SD_BALANCE_WAKE is too agressive and kbuild doesn't
      really mind too much, SD_BALANCE_NEWIDLE picks up most of the
      slack.
      
      On a dual socket, quad core, dual thread nehalem system:
      
      sysbench (--num_threads=16):
      
       SD_BALANCE_WAKE-: 13982 tx/s
       SD_BALANCE_WAKE+: 15688 tx/s
      
      kbuild (-j16):
      
       SD_BALANCE_WAKE-: 47.648295846  seconds time elapsed   ( +-   0.312% )
       SD_BALANCE_WAKE+: 47.608607360  seconds time elapsed   ( +-   0.026% )
      
      (same within noise)
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      182a85f8
  24. 15 9月, 2009 1 次提交