1. 07 2月, 2008 2 次提交
    • E
      get rid of NR_OPEN and introduce a sysctl_nr_open · 9cfe015a
      Eric Dumazet 提交于
      NR_OPEN (historically set to 1024*1024) actually forbids processes to open
      more than 1024*1024 handles.
      
      Unfortunatly some production servers hit the not so 'ridiculously high
      value' of 1024*1024 file descriptors per process.
      
      Changing NR_OPEN is not considered safe because of vmalloc space potential
      exhaust.
      
      This patch introduces a new sysctl (/proc/sys/fs/nr_open) wich defaults to
      1024*1024, so that admins can decide to change this limit if their workload
      needs it.
      
      [akpm@linux-foundation.org: export it for sparc64]
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9cfe015a
    • A
      read_current_timer() cleanups · 941e492b
      Andrew Morton 提交于
      - All implementations can be __devinit
      
      - The function prototypes were in asm/timex.h but they all must be the same,
        so create a single declaration in linux/timex.h.
      
      - uninline the sparc64 version to match the other architectures
      
      - Don't bother #defining ARCH_HAS_READ_CURRENT_TIMER to a particular value.
      
      [ezk@cs.sunysb.edu: fix build]
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      941e492b
  2. 06 2月, 2008 2 次提交
    • F
      iommu sg merging: sparc64: make iommu respect the segment size limits · fde6a3c8
      FUJITA Tomonori 提交于
      This patch makes iommu respect segment size limits when merging sg
      lists.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fde6a3c8
    • D
      timerfd: new timerfd API · 4d672e7a
      Davide Libenzi 提交于
      This is the new timerfd API as it is implemented by the following patch:
      
      int timerfd_create(int clockid, int flags);
      int timerfd_settime(int ufd, int flags,
      		    const struct itimerspec *utmr,
      		    struct itimerspec *otmr);
      int timerfd_gettime(int ufd, struct itimerspec *otmr);
      
      The timerfd_create() API creates an un-programmed timerfd fd.  The "clockid"
      parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
      
      The timerfd_settime() API give new settings by the timerfd fd, by optionally
      retrieving the previous expiration time (in case the "otmr" parameter is not
      NULL).
      
      The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
      is set in the "flags" parameter.  Otherwise it's a relative time.
      
      The timerfd_gettime() API returns the next expiration time of the timer, or
      {0, 0} if the timerfd has not been set yet.
      
      Like the previous timerfd API implementation, read(2) and poll(2) are
      supported (with the same interface).  Here's a simple test program I used to
      exercise the new timerfd APIs:
      
      http://www.xmailserver.org/timerfd-test2.c
      
      [akpm@linux-foundation.org: coding-style cleanups]
      [akpm@linux-foundation.org: fix ia64 build]
      [akpm@linux-foundation.org: fix m68k build]
      [akpm@linux-foundation.org: fix mips build]
      [akpm@linux-foundation.org: fix alpha, arm, blackfin, cris, m68k, s390, sparc and sparc64 builds]
      [heiko.carstens@de.ibm.com: fix s390]
      [akpm@linux-foundation.org: fix powerpc build]
      [akpm@linux-foundation.org: fix sparc64 more]
      Signed-off-by: NDavide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d672e7a
  3. 05 2月, 2008 1 次提交
  4. 03 2月, 2008 4 次提交
    • 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
    • M
      Add HAVE_OPROFILE · 42d4b839
      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 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: NMathieu 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: NSam Ravnborg <sam@ravnborg.org>
      42d4b839
  5. 02 2月, 2008 1 次提交
  6. 01 2月, 2008 2 次提交
  7. 31 1月, 2008 2 次提交
    • T
      SPARC64: use generic percpu · 3afc6202
      travis@sgi.com 提交于
      Sparc64 has a way of providing the base address for the per cpu area of the
      currently executing processor in a global register.
      
      Sparc64 also provides a way to calculate the address of a per cpu area
      from a base address instead of performing an array lookup.
      
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3afc6202
    • T
      percpu: change Kconfig to HAVE_SETUP_PER_CPU_AREA · 988c388a
      travis@sgi.com 提交于
      Change:
      	config ARCH_SETS_UP_PER_CPU_AREA
      to:
      	config HAVE_SETUP_PER_CPU_AREA
      
      Cc: Andi Kleen <ak@suse.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Cc: linuxppc-dev@ozlabs.org
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      988c388a
  8. 30 1月, 2008 2 次提交
  9. 29 1月, 2008 2 次提交
  10. 24 1月, 2008 1 次提交
  11. 23 1月, 2008 1 次提交
  12. 22 1月, 2008 1 次提交
    • S
      [SPARC64]: Fix of section mismatch warnings. · a1f35ba3
      Sam Ravnborg 提交于
      Fix following Section mismatch warning in sparc64:
      
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x13dec): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'psycho_scan_bus' and 'psycho_pbm_init')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x14b58): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'sabre_scan_bus' and 'sabre_init')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x15ea4): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'schizo_scan_bus' and 'schizo_pbm_init')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x17780): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'pci_sun4v_scan_bus' and 'pci_sun4v_get_head')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x17d5c): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'pci_fire_scan_bus' and 'pci_fire_get_head')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x23860): Section mismatch: reference to .devinit.text:vio_dev_release (between 'vio_create_one' and 'vio_add')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x23868): Section mismatch: reference to .devinit.text:vio_dev_release (between 'vio_create_one' and 'vio_add')
      
      The pci_* were all missing __init annotations.
      For the vio.c case it was a function with a wrong annotation which was removed.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1f35ba3
  13. 17 1月, 2008 1 次提交
  14. 13 1月, 2008 1 次提交
  15. 27 12月, 2007 1 次提交
  16. 21 12月, 2007 1 次提交
  17. 13 12月, 2007 1 次提交
    • D
      [SPARC64]: Fix two kernel linear mapping setup bugs. · 8f361453
      David S. Miller 提交于
      This was caught and identified by Greg Onufer.
      
      Since we setup the 256M/4M bitmap table after taking over the trap
      table, it's possible for some 4M mapping to get loaded in the TLB
      beforhand which later will be 256M mappings.
      
      This can cause illegal TLB multiple-match conditions.  Fix this by
      setting up the bitmap before we take over the trap table.
      
      Next, __flush_tlb_all() was not doing anything on hypervisor
      platforms.  Fix by adding sun4v_mmu_demap_all() and calling it.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f361453
  18. 12 12月, 2007 1 次提交
  19. 07 12月, 2007 1 次提交
  20. 05 12月, 2007 5 次提交
  21. 07 11月, 2007 1 次提交
  22. 01 11月, 2007 5 次提交
  23. 27 10月, 2007 1 次提交