1. 11 Nov, 2008 1 commit
  2. 20 Oct, 2008 1 commit
    • Matt Helsley's avatar
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley authored
      
      
      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: default avatarCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  3. 17 Oct, 2008 2 commits
  4. 16 Oct, 2008 1 commit
  5. 06 Oct, 2008 1 commit
  6. 04 Aug, 2008 2 commits
  7. 17 Jul, 2008 1 commit
  8. 26 Jun, 2008 1 commit
  9. 14 May, 2008 1 commit
  10. 29 Apr, 2008 2 commits
  11. 27 Apr, 2008 1 commit
  12. 22 Apr, 2008 1 commit
  13. 09 Apr, 2008 1 commit
  14. 04 Mar, 2008 2 commits
  15. 20 Feb, 2008 1 commit
    • Hidetoshi Seto's avatar
      [IA64] VIRT_CPU_ACCOUNTING (accurate cpu time accounting) · b64f34cd
      Hidetoshi Seto authored
      
      
      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: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      b64f34cd
  16. 11 Feb, 2008 1 commit
    • Tony Luck's avatar
      [IA64] Fix build for sim_defconfig · 10d0aa3c
      Tony Luck authored
      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: default avatarTony Luck <tony.luck@intel.com>
      10d0aa3c
  17. 09 Feb, 2008 1 commit
  18. 03 Feb, 2008 4 commits
    • Adrian Bunk's avatar
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk authored
      
      
      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: default avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
      03502faa
    • Mathieu Desnoyers's avatar
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers authored
      
      
      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: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      125e5645
    • Mathieu Desnoyers's avatar
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers authored
      
      
      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: default avatarMathieu 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: default avatarSam Ravnborg <sam@ravnborg.org>
      3f550096
    • Mathieu Desnoyers's avatar
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers authored
      
      
      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 ARCH_SUPPORTS_KPROBES
                      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...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      42d4b839
  19. 30 Jan, 2008 3 commits
  20. 19 Oct, 2007 2 commits
  21. 17 Oct, 2007 1 commit
  22. 16 Oct, 2007 3 commits
  23. 12 Oct, 2007 1 commit
    • Bjorn Helgaas's avatar
      [IA64] add driver for ACPI methods to call native firmware · 28eda5b8
      Bjorn Helgaas authored
      
      
      This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
      AML methods can use this OpRegion to call native firmware entry points.
      
      ACPI does not define a mechanism for AML methods to call native firmware
      interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
      After the handler is installed, an AML method can call native firmware by
      storing the arguments and firmware entry point to specific offsets in the
      OpRegion.  When AML reads the "return value" offset from the OpRegion, this
      handler loads up the arguments, makes the firmware call, and returns the
      result.
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      28eda5b8
  24. 13 Aug, 2007 1 commit
    • Satyam Sharma's avatar
      [IA64] Include Kconfig.preempt · 0b0517a4
      Satyam Sharma authored
      
      
      arch/ia64/Kconfig failed to include kernel/Kconfig.preempt that meant it
      did not support PREEMPT_VOLUNTARY and PREEMPT_BKL (inadvertently).
      This was recently noticed when the newly-added PREEMPT_NOTIFIERS in
      Kconfig.preempt that was "select"ed from drivers/kvm/Kconfig (therefore)
      started giving bogus warnings ('select' used by config symbol 'KVM' refers
      to undefined symbol 'PREEMPT_NOTIFIERS') on ia64 builds.
      
      So let's remove the open-coded definition of CONFIG_PREEMPT in
      arch/ia64/Kconfig and replace it with just including Kconfig.preempt
      instead, like the other archs do.
      Signed-off-by: default avatarSatyam Sharma <satyam@infradead.org>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      0b0517a4
  25. 27 Jul, 2007 1 commit
    • Tony Luck's avatar
      [IA64] Fix build failure in fs/quota.c · 7a6c8135
      Tony Luck authored
      b716395e
      
       added code to handle
      a compatability issue with 32bit quota tools, but the new compat
      routines are only needed when CONFIG_COMPAT=y (and with this set
      to 'n' there are compilation problems since some new typedefs are
      not visible).
      
      Reported by Doug Chapman.  Fix tuned by a cast of thousands (Andi,
      Andreas, Arthur, HPA, Willy)
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      7a6c8135
  26. 20 Jul, 2007 1 commit
  27. 17 Jul, 2007 1 commit
  28. 11 Jul, 2007 1 commit