Skip to content
Snippets Groups Projects
This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git. Pull mirroring updated .
  1. Feb 08, 2008
  2. Feb 07, 2008
  3. Feb 06, 2008
  4. Feb 05, 2008
  5. Feb 03, 2008
    • 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
      Create arch/Kconfig · fb32e03f
      Mathieu Desnoyers authored
      
      Puts the content of arch/Kconfig in the "General setup" menu.
      
      Linus:
      
      > Should it come with a re-duplication of it's content into each
      > architecture, which was the case previously ? The oprofile and kprobes
      > menu entries were litteraly cut and pasted from one architecture to
      > another. Should we put its content in init/Kconfig then ?
      
      I don't think it's a good idea to go back to making it per-architecture,
      although that extensive "depends on <list-of-archiectures-here>" might
      indicate that there certainly is room for cleanup there.
      
      And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I
      just think it's wrong to (a) lump the code together when it really doesn't
      necessarily need to and (b) show it to users as some kind of choice that
      is tied together (whether it then has common code or not).
      
      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...
      
      Sam Ravnborg:
      
      Stuff it into a new file: arch/Kconfig
      We can then extend this file to include all the 'trailing'
      Kconfig things that are anyway equal for all ARCHs.
      
      But it should be kept clean - so if we introduce such a file
      then we should use ARCH_HAS_whatever in the arch specific Kconfig
      files to enable stuff that is not shared.
      
      [...]
      
      The above suggestion is actually not exactly the best way to do it...
      First the naming..
      A quick grep shows following usage today (in Kconfig files)
      ARCH_HAS        51
      ARCH_SUPPORTS   4
      HAVE_ARCH       7
      
      ARCH_HAS is the clear winner.
      
      In the common Kconfig file do:
      
      config FOO
              depends on ARCH_HAS_FOO
              bool "bla bla"
      
      config ARCH_HAS_FOO
              def_bool n
      
      In the arch specific Kconfig file in a suitable place do:
      
      config SUITABLE_OPTION
              select ARCH_HAS_FOO
      
      The naming of ARCH_HAS_ is fixed and shall be:
      ARCH_HAS_<config option it will enable>
      
      Only a single line added pr. architecture.
      And we will end up with a (maybe even commented) list of trivial selects.
      
      - Yet another update :
      
      Moving to HAVE_* now.
      
      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>
      fb32e03f
  6. Jan 31, 2008
  7. Jan 30, 2008
  8. Jan 28, 2008
  9. Jan 25, 2008
    • Paul E. McKenney's avatar
      Preempt-RCU: implementation · e260be67
      Paul E. McKenney authored
      This patch implements a new version of RCU which allows its read-side
      critical sections to be preempted. It uses a set of counter pairs
      to keep track of the read-side critical sections and flips them
      when all tasks exit read-side critical section. The details
      of this implementation can be found in this paper -
      
      	http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
      
      and the article-
      
      	http://lwn.net/Articles/253651/
      
      
      
      This patch was developed as a part of the -rt kernel development and
      meant to provide better latencies when read-side critical sections of
      RCU don't disable preemption.  As a consequence of keeping track of RCU
      readers, the readers have a slight overhead (optimizations in the paper).
      This implementation co-exists with the "classic" RCU implementations
      and can be switched to at compiler.
      
      Also includes RCU tracing summarized in debugfs.
      
      [ akpm@linux-foundation.org: build fixes on non-preempt architectures ]
      
      Signed-off-by: default avatarGautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: default avatarDipankar Sarma <dipankar@in.ibm.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@us.ibm.com>
      Reviewed-by: default avatarSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e260be67
    • Gautham R Shenoy's avatar
      cpu-hotplug: refcount based cpu hotplug · d221938c
      Gautham R Shenoy authored
      
      This patch implements a Refcount + Waitqueue based model for
      cpu-hotplug.
      
      Now, a thread which wants to prevent cpu-hotplug, will bump up a global
      refcount and the thread which wants to perform a cpu-hotplug operation
      will block till the global refcount goes to zero.
      
      The readers, if any, during an ongoing cpu-hotplug operation are blocked
      until the cpu-hotplug operation is over.
      
      Signed-off-by: default avatarGautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: Paul Jackson <pj@sgi.com> [For !CONFIG_HOTPLUG_CPU ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d221938c
    • Randy Dunlap's avatar
      sysfs: make SYSFS_DEPRECATED depend on SYSFS · 9148fe87
      Randy Dunlap authored
      
      Make SYSFS_DEPRECATED depend on SYSFS since files that check
      CONFIG_SYSFS_DEPRECATED don't check for CONFIG_SYSFS first.
      Also don't prompt user about SYSFS_DEPRECATED if SYSFS=n.
      
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9148fe87
    • Kay Sievers's avatar
      Driver core: convert block from raw kobjects to core devices · edfaa7c3
      Kay Sievers authored
      
      This moves the block devices to /sys/class/block. It will create a
      flat list of all block devices, with the disks and partitions in one
      directory. For compatibility /sys/block is created and contains symlinks
      to the disks.
      
        /sys/class/block
        |-- sda -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
        |-- sda1 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1
        |-- sda10 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda10
        |-- sda5 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda5
        |-- sda6 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda6
        |-- sda7 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda7
        |-- sda8 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda8
        |-- sda9 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda9
        `-- sr0 -> ../../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
      
        /sys/block/
        |-- sda -> ../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
        `-- sr0 -> ../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
      
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      edfaa7c3
    • H. Peter Anvin's avatar
      security: remove security_sb_post_mountroot hook · bced9528
      H. Peter Anvin authored
      The security_sb_post_mountroot() hook is long-since obsolete, and is
      fundamentally broken: it is never invoked if someone uses initramfs.
      This is particularly damaging, because the existence of this hook has
      been used as motivation for not using initramfs.
      
      Stephen Smalley confirmed on 2007-07-19 that this hook was originally
      used by SELinux but can now be safely removed:
      
           http://marc.info/?l=linux-kernel&m=118485683612916&w=2
      
      
      
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      bced9528
  10. Jan 02, 2008
  11. Dec 02, 2007
    • Srivatsa Vaddagiri's avatar
      sched: cpu accounting controller (V2) · d842de87
      Srivatsa Vaddagiri authored
      
      Commit cfb52856 removed a useful feature for
      us, which provided a cpu accounting resource controller.  This feature would be
      useful if someone wants to group tasks only for accounting purpose and doesnt
      really want to exercise any control over their cpu consumption.
      
      The patch below reintroduces the feature. It is based on Paul Menage's
      original patch (Commit 62d0df64), with
      these differences:
      
              - Removed load average information. I felt it needs more thought (esp
      	  to deal with SMP and virtualized platforms) and can be added for
      	  2.6.25 after more discussions.
              - Convert group cpu usage to be nanosecond accurate (as rest of the cfs
      	  stats are) and invoke cpuacct_charge() from the respective scheduler
      	  classes
      	- Make accounting scalable on SMP systems by splitting the usage
      	  counter to be per-cpu
      	- Move the code from kernel/cpu_acct.c to kernel/sched.c (since the
      	  code is not big enough to warrant a new file and also this rightly
      	  needs to live inside the scheduler. Also things like accessing
      	  rq->lock while reading cpu usage becomes easier if the code lived in
      	  kernel/sched.c)
      
      The patch also modifies the cpu controller not to provide the same accounting
      information.
      
      Tested-by: default avatarBalbir Singh <balbir@linux.vnet.ibm.com>
      
       Tested the patches on top of 2.6.24-rc3. The patches work fine. Ran
       some simple tests like cpuspin (spin on the cpu), ran several tasks in
       the same group and timed them. Compared their time stamps with
       cpuacct.usage.
      
      Signed-off-by: default avatarSrivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
      Signed-off-by: default avatarBalbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d842de87
  12. Nov 21, 2007
  13. Nov 23, 2007
  14. Nov 15, 2007
    • Eric W. Biederman's avatar
      pidns: Place under CONFIG_EXPERIMENTAL · 57d5f66b
      Eric W. Biederman authored
      
      This is my trivial patch to swat innumerable little bugs with a single
      blow.
      
      After some intensive review (my apologies for not having gotten to this
      sooner) what we have looks like a good base to build on with the current
      pid namespace code but it is not complete, and it is still much to simple
      to find issues where the kernel does the wrong thing outside of the initial
      pid namespace.
      
      Until the dust settles and we are certain we have the ABI and the
      implementation is as correct as humanly possible let's keep process ID
      namespaces behind CONFIG_EXPERIMENTAL.
      
      Allowing us the option of fixing any ABI or other bugs we find as long as
      they are minor.
      
      Allowing users of the kernel to avoid those bugs simply by ensuring their
      kernel does not have support for multiple pid namespaces.
      
      [akpm@linux-foundation.org: coding-style cleanups]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Adrian Bunk <bunk@kernel.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Kir Kolyshkin <kir@swsoft.com>
      Cc: Kirill Korotaev <dev@sw.ru>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57d5f66b
    • Andrew Morton's avatar
      revert "Task Control Groups: example CPU accounting subsystem" · cfb52856
      Andrew Morton authored
      
      Revert 62d0df64.
      
      This was originally intended as a simple initial example of how to create a
      control groups subsystem; it wasn't intended for mainline, but I didn't make
      this clear enough to Andrew.
      
      The CFS cgroup subsystem now has better functionality for the per-cgroup usage
      accounting (based directly on CFS stats) than the "usage" status file in this
      patch, and the "load" status file is rather simplistic - although having a
      per-cgroup load average report would be a useful feature, I don't believe this
      patch actually provides it.  If it gets into the final 2.6.24 we'd probably
      have to support this interface for ever.
      
      Cc: Paul Menage <menage@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cfb52856
  15. Nov 09, 2007
Loading