1. 09 2月, 2010 1 次提交
    • T
      [IA64] Remove COMPAT_IA32 support · 32974ad4
      Tony Luck 提交于
      This has been broken since May 2008 when Al Viro killed altroot support.
      Since nobody has complained, it would appear that there are no users of
      this code (A plausible theory since the main OSVs that support ia64 prefer
      to use the IA32-EL software emulation).
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      32974ad4
  2. 02 10月, 2009 1 次提交
    • T
      ia64: convert to dynamic percpu allocator · 52594762
      Tejun Heo 提交于
      Unlike other archs, ia64 reserves space for percpu areas during early
      memory initialization.  These areas occupy a contiguous region indexed
      by cpu number on contiguous memory model or are grouped by node on
      discontiguous memory model.
      
      As allocation and initialization are done by the arch code, all that
      setup_per_cpu_areas() needs to do is communicating the determined
      layout to the percpu allocator.  This patch implements
      setup_per_cpu_areas() for both contig and discontig memory models and
      drops HAVE_LEGACY_PER_CPU_AREA.
      
      Please note that for contig model, the allocation itself is modified
      only to allocate for possible cpus instead of NR_CPUS.  As dynamic
      percpu allocator can handle non-direct mapping, there's no reason to
      allocate memory for cpus which aren't possible.
      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>
      52594762
  3. 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
  4. 23 9月, 2009 1 次提交
  5. 27 8月, 2009 1 次提交
  6. 24 6月, 2009 1 次提交
    • T
      percpu: use dynamic percpu allocator as the default percpu allocator · e74e3962
      Tejun Heo 提交于
      This patch makes most !CONFIG_HAVE_SETUP_PER_CPU_AREA archs use
      dynamic percpu allocator.  The first chunk is allocated using
      embedding helper and 8k is reserved for modules.  This ensures that
      the new allocator behaves almost identically to the original allocator
      as long as static percpu variables are concerned, so it shouldn't
      introduce much breakage.
      
      s390 and alpha use custom SHIFT_PERCPU_PTR() to work around addressing
      range limit the addressing model imposes.  Unfortunately, this breaks
      if the address is specified using a variable, so for now, the two
      archs aren't converted.
      
      The following architectures are affected by this change.
      
      * sh
      * arm
      * cris
      * mips
      * sparc(32)
      * blackfin
      * avr32
      * parisc (broken, under investigation)
      * m32r
      * powerpc(32)
      
      As this change makes the dynamic allocator the default one,
      CONFIG_HAVE_DYNAMIC_PER_CPU_AREA is replaced with its invert -
      CONFIG_HAVE_LEGACY_PER_CPU_AREA, which is added to yet-to-be converted
      archs.  These archs implement their own setup_per_cpu_areas() and the
      conversion is not trivial.
      
      * powerpc(64)
      * sparc(64)
      * ia64
      * alpha
      * s390
      
      Boot and batch alloc/free tests on x86_32 with debug code (x86_32
      doesn't use default first chunk initialization).  Compile tested on
      sparc(32), powerpc(32), arm and alpha.
      
      Kyle McMartin reported that this change breaks parisc.  The problem is
      still under investigation and he is okay with pushing this patch
      forward and fixing parisc later.
      
      [ Impact: use dynamic allocator for most archs w/o custom percpu setup ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Reviewed-by: NChristoph Lameter <cl@linux.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Bryan Wu <cooloney@kernel.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      e74e3962
  7. 19 6月, 2009 1 次提交
  8. 26 2月, 2009 1 次提交
  9. 20 2月, 2009 2 次提交
  10. 16 1月, 2009 1 次提交
    • T
      [IA64] Turn on CONFIG_HAVE_UNSTABLE_CLOCK · 0773a6cf
      Tony Luck 提交于
      sched_clock() on ia64 is based on ar.itc, so is never
      completely synchronized between cpus. On some platforms
      (e.g. certain models of SGI Altix) it may be running at
      radically different frequencies.
      
      Based on a patch from Dimitri Sivanich which set this
      just for SN2 && GENERIC kernels ... it is needed for
      all ia64 machines.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      0773a6cf
  11. 14 1月, 2009 2 次提交
    • S
      ftrace, ia64: IA64 dynamic ftrace support · a14a07b8
      Shaohua Li 提交于
      IA64 dynamic ftrace support.
      The original _mcount stub for each function is like:
      	alloc r40=ar.pfs,12,8,0
      	mov r43=r0;;
      	mov r42=b0
      	mov r41=r1
      	nop.i 0x0
      	br.call.sptk.many b0 = _mcount;;
      
      The patch convert it to below for nop:
      	[MII] nop.m 0x0
      	mov r3=ip
      	nop.i 0x0
      	[MLX] nop.m 0x0
      	nop.x 0x0;;
      This isn't completely nop, as there is one instuction 'mov r3=ip', but
      it should be light and harmless for code follow it.
      
      And below is for call
      	[MII] nop.m 0x0
      	mov r3=ip
      	nop.i 0x0
      	[MLX] nop.m 0x0
      	brl.many .;;
      In this way, only one instruction is changed to convert code between nop
      and call. This should meet dyn-ftrace's requirement.
      But this requires CPU support brl instruction, so dyn-ftrace isn't
      supported for old Itanium system. Assume there are quite few such old
      system running.
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a14a07b8
    • S
      ftrace, ia64: IA64 static ftrace support · d3e75ff1
      Shaohua Li 提交于
      IA64 ftrace suppport. In IA64, below code will be added in each function
      if -pg is enabled.
      
      alloc r40=ar.pfs,12,8,0
      mov r43=r0;;
      mov r42=b0
      mov r41=r1
      nop.i 0x0
      br.call.sptk.many b0 = _mcount;;
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3e75ff1
  12. 03 1月, 2009 1 次提交
  13. 11 11月, 2008 1 次提交
  14. 07 11月, 2008 1 次提交
  15. 05 11月, 2008 1 次提交
  16. 20 10月, 2008 1 次提交
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley 提交于
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  17. 18 10月, 2008 2 次提交
  18. 17 10月, 2008 1 次提交
  19. 07 10月, 2008 1 次提交
  20. 05 8月, 2008 2 次提交
  21. 18 7月, 2008 1 次提交
  22. 26 6月, 2008 1 次提交
  23. 15 5月, 2008 1 次提交
  24. 29 4月, 2008 2 次提交
  25. 27 4月, 2008 1 次提交
  26. 23 4月, 2008 1 次提交
  27. 10 4月, 2008 1 次提交
  28. 05 3月, 2008 2 次提交
  29. 21 2月, 2008 1 次提交
    • H
      [IA64] VIRT_CPU_ACCOUNTING (accurate cpu time accounting) · b64f34cd
      Hidetoshi Seto 提交于
      This patch implements VIRT_CPU_ACCOUNTING for ia64,
      which enable us to use more accurate cpu time accounting.
      
      The VIRT_CPU_ACCOUNTING is an item of kernel config, which s390
      and powerpc arch have.  By turning this config on, these archs
      change the mechanism of cpu time accounting from tick-sampling
      based one to state-transition based one.
      
      The state-transition based accounting is done by checking time
      (cycle counter in processor) at every state-transition point,
      such as entrance/exit of kernel, interrupt, softirq etc.
      The difference between point to point is the actual time consumed
      during in the state. There is no doubt about that this value is
      more accurate than that of tick-sampling based accounting.
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      b64f34cd
  30. 12 2月, 2008 1 次提交
    • T
      [IA64] Fix build for sim_defconfig · 10d0aa3c
      Tony Luck 提交于
      Commit bdc80787 broke the build
      for this config because the sim_defconfig selects CONFIG_HZ=250
      but include/asm-ia64/param.h has an ifdef for the simulator to
      force HZ to 32.  So we ended up with a kernel/timeconst.h set
      for HZ=250 ... which then failed the check for the right HZ
      value and died with:
      
      Drop the #ifdef magic from param.h and make force CONFIG_HZ=32
      directly for the simulator.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      10d0aa3c
  31. 09 2月, 2008 1 次提交
  32. 03 2月, 2008 3 次提交
    • A
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk 提交于
      After seeing the filename I'd have expected something about the
      implementation of SMP in the Linux kernel - not some notes on kernel
      configuration and building trivialities noone would search at this
      place.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      03502faa
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      init/Kconfig for architecture independent options
        - profiling
        - markers
      
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096