An error occurred fetching the project authors.
  1. 30 Apr, 2008 1 commit
  2. 29 Apr, 2008 2 commits
  3. 28 Apr, 2008 2 commits
  4. 27 Apr, 2008 2 commits
  5. 26 Apr, 2008 7 commits
    • Alexander van Heukelum's avatar
      x86, bitops: select the generic bitmap search functions · 19870def
      Alexander van Heukelum authored
      Introduce GENERIC_FIND_FIRST_BIT and GENERIC_FIND_NEXT_BIT in
      lib/Kconfig, defaulting to off. An arch that wants to use the
      generic implementation now only has to use a select statement
      to include them.
      
      I added an always-y option (X86_CPU) to arch/x86/Kconfig.cpu
      and used that to select the generic search functions. This
      way ARCH=um SUBARCH=i386 automatically picks up the change
      too, and arch/um/Kconfig.i386 can therefore be simplified a
      bit. ARCH=um SUBARCH=x86_64 does things differently, but
      still compiles fine. It seems that a "def_bool y" always
      wins over a "def_bool n"?
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      19870def
    • Alexander van Heukelum's avatar
      x86: switch 64-bit to generic find_first_bit · 2aba6925
      Alexander van Heukelum authored
      Switch x86_64 to generic find_first_bit. The x86_64-specific
      implementation is not removed.
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      2aba6925
    • Alexander van Heukelum's avatar
      x86: generic versions of find_first_(zero_)bit, convert i386 · 77b9bd9c
      Alexander van Heukelum authored
      Generic versions of __find_first_bit and __find_first_zero_bit
      are introduced as simplified versions of __find_next_bit and
      __find_next_zero_bit. Their compilation and use are guarded by
      a new config variable GENERIC_FIND_FIRST_BIT.
      
      The generic versions of find_first_bit and find_first_zero_bit
      are implemented in terms of the newly introduced __find_first_bit
      and __find_first_zero_bit.
      
      This patch does not remove the i386-specific implementation,
      but it does switch i386 to use the generic functions by setting
      GENERIC_FIND_FIRST_BIT=y for X86_32.
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      77b9bd9c
    • Alexander van Heukelum's avatar
      x86: change x86 to use generic find_next_bit · 6fd92b63
      Alexander van Heukelum authored
      The versions with inline assembly are in fact slower on the machines I
      tested them on (in userspace) (Athlon XP 2800+, p4-like Xeon 2.8GHz, AMD
      Opteron 270). The i386-version needed a fix similar to 06024f21 to avoid
      crashing the benchmark.
      
      Benchmark using: gcc -fomit-frame-pointer -Os. For each bitmap size
      1...512, for each possible bitmap with one bit set, for each possible
      offset: find the position of the first bit starting at offset. If you
      follow ;). Times include setup of the bitmap and checking of the
      results.
      
      		Athlon		Xeon		Opteron 32/64bit
      x86-specific:	0m3.692s	0m2.820s	0m3.196s / 0m2.480s
      generic:	0m2.622s	0m1.662s	0m2.100s / 0m1.572s
      
      If the bitmap size is not a multiple of BITS_PER_LONG, and no set
      (cleared) bit is found, find_next_bit (find_next_zero_bit) returns a
      value outside of the range [0, size]. The generic version always returns
      exactly size. The generic version also uses unsigned long everywhere,
      while the x86 versions use a mishmash of int, unsigned (int), long and
      unsigned long.
      
      Using the generic version does give a slightly bigger kernel, though.
      
      defconfig:	   text    data     bss     dec     hex filename
      x86-specific:	4738555  481232  626688 5846475  5935cb vmlinux (32 bit)
      generic:	4738621  481232  626688 5846541  59360d vmlinux (32 bit)
      x86-specific:	5392395  846568  724424 6963387  6a40bb vmlinux (64 bit)
      generic:	5392458  846568  724424 6963450  6a40fa vmlinux (64 bit)
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6fd92b63
    • Ingo Molnar's avatar
      x86 PAT: decouple from nonpromisc devmem · 2a8a2719
      Ingo Molnar authored
      Linus pointed it out that PAT should not depend on NONPROMISC_DEVMEM.
      
      Also make PAT non-default.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2a8a2719
    • Ingo Molnar's avatar
      generic: make optimized inlining arch-opt-in · 765c68bd
      Ingo Molnar authored
      Stephen Rothwell reported that linux-next did not build on powerpc64.
      
      make optimized inlining dependent on architecture opt-in.
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      765c68bd
    • Ingo Molnar's avatar
      x86 PAT: decouple from nonpromisc devmem · 8db979bc
      Ingo Molnar authored
      Linus pointed it out that PAT should not depend on NONPROMISC_DEVMEM.
      
      Also make PAT non-default.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8db979bc
  6. 24 Apr, 2008 1 commit
  7. 19 Apr, 2008 2 commits
  8. 17 Apr, 2008 12 commits
  9. 12 Mar, 2008 1 commit
  10. 11 Mar, 2008 1 commit
    • Thomas Gleixner's avatar
      x86: remove quicklists · 985a34bd
      Thomas Gleixner authored
      quicklists cause a serious memory leak on 32-bit x86,
      as documented at:
      
        http://bugzilla.kernel.org/show_bug.cgi?id=9991
      
      the reason is that the quicklist pool is a special-purpose
      cache that grows out of proportion. It is not accounted for
      anywhere and users have no way to even realize that it's
      the quicklists that are causing RAM usage spikes. It was
      supposed to be a relatively small pool, but as demonstrated
      by KOSAKI Motohiro, they can grow as large as:
      
        Quicklists:    1194304 kB
      
      given how much trouble this code has caused historically,
      and given that Andrew objected to its introduction on x86
      (years ago), the best option at this point is to remove them.
      
      [ any performance benefits of caching constructed pgds should
        be implemented in a more generic way (possibly within the page
        allocator), while still allowing constructed pages to be
        allocated by other workloads. ]
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      985a34bd
  11. 05 Mar, 2008 1 commit
  12. 04 Mar, 2008 1 commit
  13. 22 Feb, 2008 1 commit
    • Linus Torvalds's avatar
      Mark CC_STACKPROTECTOR as being BROKEN · 2c020a99
      Linus Torvalds authored
      It's always been broken, but recent fixes actually made it do something,
      and now the brokenness shows up as the resulting kernel simply not
      working at all.
      
      So it used to be that you could enable this config option, and it just
      didn't do anything.  Now we'd better stop people from enabling it by
      mistake, since it _does_ do something, but does it so badly as to be
      unusable.
      
      Code to actually make it work is pending, but incomplete and won't be
      merged into 2.6.25 in any case.
      Acked-by: default avatarArjan van de Ven <arjan@infradead.org>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2c020a99
  14. 14 Feb, 2008 1 commit
  15. 09 Feb, 2008 2 commits
  16. 08 Feb, 2008 2 commits
    • David Howells's avatar
      aout: mark arches that support A.OUT format · b0b933c0
      David Howells authored
      Mark arches that support A.OUT format by including the following in their
      master Kconfig files:
      
      	config ARCH_SUPPORTS_AOUT
      		def_bool y
      
      This should also be set if the arch provides compatibility A.OUT support for
      an older arch, for instance x86_64 for i386 or sparc64 for sparc.
      
      I've guessed at which arches don't, based on comments in the code, however I'm
      sure that some of the ones I've marked as 'yes' actually should be 'no'.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b0b933c0
    • Christoph Lameter's avatar
      SLUB: Alternate fast paths using cmpxchg_local · 1f84260c
      Christoph Lameter authored
      Provide an alternate implementation of the SLUB fast paths for alloc
      and free using cmpxchg_local. The cmpxchg_local fast path is selected
      for arches that have CONFIG_FAST_CMPXCHG_LOCAL set. An arch should only
      set CONFIG_FAST_CMPXCHG_LOCAL if the cmpxchg_local is faster than an
      interrupt enable/disable sequence. This is known to be true for both
      x86 platforms so set FAST_CMPXCHG_LOCAL for both arches.
      
      Currently another requirement for the fastpath is that the kernel is
      compiled without preemption. The restriction will go away with the
      introduction of a new per cpu allocator and new per cpu operations.
      
      The advantages of a cmpxchg_local based fast path are:
      
      1. Potentially lower cycle count (30%-60% faster)
      
      2. There is no need to disable and enable interrupts on the fast path.
         Currently interrupts have to be disabled and enabled on every
         slab operation. This is likely avoiding a significant percentage
         of interrupt off / on sequences in the kernel.
      
      3. The disposal of freed slabs can occur with interrupts enabled.
      
      The alternate path is realized using #ifdef's. Several attempts to do the
      same with macros and inline functions resulted in a mess (in particular due
      to the strange way that local_interrupt_save() handles its argument and due
      to the need to define macros/functions that sometimes disable interrupts
      and sometimes do something else).
      
      [clameter: Stripped preempt bits and disabled fastpath if preempt is enabled]
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Reviewed-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      1f84260c
  17. 07 Feb, 2008 1 commit