1. 23 10月, 2008 1 次提交
  2. 20 10月, 2008 3 次提交
    • A
      alpha: use bcd2bin/bin2bcd · 18b1bd05
      Adrian Bunk 提交于
      Change alpha to use the new bcd2bin/bin2bcd functions instead of the
      obsolete BCD_TO_BIN/BIN_TO_BCD macros.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      18b1bd05
    • 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
    • M
      container freezer: add TIF_FREEZE flag to all architectures · 83224b08
      Matt Helsley 提交于
      This patch series introduces a cgroup subsystem that utilizes the swsusp
      freezer to freeze a group of tasks.  It's immediately useful for batch job
      management scripts.  It should also be useful in the future for
      implementing container checkpoint/restart.
      
      The freezer subsystem in the container filesystem defines a cgroup file
      named freezer.state.  Reading freezer.state will return the current state
      of the cgroup.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.
      
      * 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 patch:
      
      The first step in making the refrigerator() available to all
      architectures, even for those without power management.
      
      The purpose of such a change is to be able to use the refrigerator() in a
      new control group subsystem which will implement a control group freezer.
      
      [akpm@linux-foundation.org: fix sparc]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@tuxonice.net>
      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>
      83224b08
  3. 17 10月, 2008 4 次提交
  4. 16 10月, 2008 3 次提交
  5. 07 10月, 2008 2 次提交
  6. 09 9月, 2008 1 次提交
    • M
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      Manfred Spraul 提交于
      Right now, there is no notifier that is called on a new cpu, before the new
      cpu begins processing interrupts/softirqs.
      Various kernel function would need that notification, e.g. kvm works around
      by calling smp_call_function_single(), rcu polls cpu_online_map.
      
      The patch adds a CPU_STARTING notification. It also adds a helper function
      that sends the message to all cpu_chain handlers.
      
      Tested on x86-64.
      All other archs are untested. Especially on sparc, I'm not sure if I got
      it right.
      Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e545a614
  7. 07 9月, 2008 2 次提交
  8. 04 9月, 2008 1 次提交
  9. 25 8月, 2008 1 次提交
  10. 16 8月, 2008 1 次提交
  11. 27 7月, 2008 2 次提交
  12. 26 7月, 2008 1 次提交
    • T
      inflate: refactor inflate malloc code · 2d6ffcca
      Thomas Petazzoni 提交于
      Inflate requires some dynamic memory allocation very early in the boot
      process and this is provided with a set of four functions:
      malloc/free/gzip_mark/gzip_release.
      
      The old inflate code used a mark/release strategy rather than implement
      free.  This new version instead keeps a count on the number of outstanding
      allocations and when it hits zero, it resets the malloc arena.
      
      This allows removing all the mark and release implementations and unifying
      all the malloc/free implementations.
      
      The architecture-dependent code must define two addresses:
       - free_mem_ptr, the address of the beginning of the area in which
         allocations should be made
       - free_mem_end_ptr, the address of the end of the area in which
         allocations should be made. If set to 0, then no check is made on
         the number of allocations, it just grows as much as needed
      
      The architecture-dependent code can also provide an arch_decomp_wdog()
      function call.  This function will be called several times during the
      decompression process, and allow to notify the watchdog that the system is
      still running.  If an architecture provides such a call, then it must
      define ARCH_HAS_DECOMP_WDOG so that the generic inflate code calls
      arch_decomp_wdog().
      
      Work initially done by Matt Mackall, updated to a recent version of the
      kernel and improved by me.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Mikael Starvik <mikael.starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      Acked-by: NYoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d6ffcca
  13. 25 7月, 2008 4 次提交
  14. 05 7月, 2008 1 次提交
  15. 26 6月, 2008 3 次提交
  16. 21 6月, 2008 3 次提交
    • I
      alpha: resurrect Cypress IDE quirk · a744e016
      Ivan Kokshaysky 提交于
      Which was removed in the hope that generic legacy IDE quirk in
      drivers/pci/probe.c is sufficient for Cypress IDE.
      It isn't, as this controller has non-standard BAR layout:
      secondary channel registers are in the BAR0-1 of the second
      PCI function - not in the BAR2-3 of the same function, as the
      generic quirk routine assumes.
      Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a744e016
    • I
      alpha: fix compile failures with gcc-4.3 (bug #10438) · d559d4a2
      Ivan Kokshaysky 提交于
      Vast majority of these build failures are gcc-4.3 warnings
      about static functions and objects being referenced from
      non-static (read: "extern inline") functions, in conjunction
      with our -Werror.
      
      We cannot just convert "extern inline" to "static inline",
      as people keep suggesting all the time, because "extern inline"
      logic is crucial for generic kernel build.
      So
      - just make sure that all callees of critical "extern inline"
        functions are also "extern inline";
      - use "static inline", wherever it's possible.
      
      traps.c: work around gcc-4.3 being too smart about array
      bounds-checking.
      
      TODO: add "gnu_inline" attribute to all our "extern inline"
      functions to ensure desired behaviour with future compilers.
      Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d559d4a2
    • I
      alpha: link failure fix · ede42692
      Ivan Kokshaysky 提交于
      With built-in scsi disk driver, the final link fails with a following
      error:
      `.exit.text' referenced in section `.rodata' of drivers/built-in.o:
      defined in discarded section `.exit.text' of drivers/built-in.o
      
      This happens with -Os (CONFIG_CC_OPTIMIZE_FOR_SIZE=y) with all gcc-4
      versions, and also with -O2 and gcc-4.3.
      
      The problem is in sd.c:sd_major() being inlined into __exit function
      exit_sd(), and the compiler generating a jump table in .rodata section
      for the 'switch' statement in sd_major(). So we have references to
      discarded section.
      
      Fixed with a big hammer in the form of -fno-jump-tables.
      
      Note that jump tables vs. discarded sections is a generic problem,
      other architectures are just lucky not to suffer from it. But with
      a slightly more complex switch/case statement it can be reproduced
      on x86 as well. So maybe at some point we should consider
      -fno-jump-tables as a generic compile option...
      Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ede42692
  17. 05 6月, 2008 1 次提交
    • M
      genirq: Expose default irq affinity mask (take 3) · 18404756
      Max Krasnyansky 提交于
      Current IRQ affinity interface does not provide a way to set affinity
      for the IRQs that will be allocated/activated in the future.
      This patch creates /proc/irq/default_smp_affinity that lets users set
      default affinity mask for the newly allocated IRQs. Changing the default
      does not affect affinity masks for the currently active IRQs, they
      have to be changed explicitly.
      
      Updated based on Paul J's comments and added some more documentation.
      Signed-off-by: NMax Krasnyansky <maxk@qualcomm.com>
      Cc: pj@sgi.com
      Cc: a.p.zijlstra@chello.nl
      Cc: tglx@linutronix.de
      Cc: rdunlap@xenotime.net
      Cc: mingo@elte.hu
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      18404756
  18. 17 5月, 2008 1 次提交
  19. 02 5月, 2008 1 次提交
  20. 29 4月, 2008 2 次提交
  21. 28 4月, 2008 2 次提交
新手
引导
客服 返回
顶部