SLUB: Use ilog2 instead of series of constant comparisons.

SLUB: Use ilog2 instead of series of constant comparisons.

[Christoph Lameter]

I finally found a way to get rid of the nasty list of comparisions in
slub_def.h. ilog2 seems to work right for constants.

Also update comments

Drop the generation of an unresolved symbol for the case that the size is
too big. A simple BUG_ON sufficies now that we can alloc up to MAX_ORDER
size slab objects.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

---
 include/linux/slub_def.h |   66 ++++++++++++++---------------------------------
 1 file changed, 20 insertions(+), 46 deletions(-)

Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h	2007-05-21 11:38:19.000000000 -0700
+++ slub/include/linux/slub_def.h	2007-05-21 11:58:16.000000000 -0700
@@ -10,6 +10,7 @@
 #include <linux/gfp.h>
 #include <linux/workqueue.h>
 #include <linux/kobject.h>
+#include <linux/log2.h>
 
 struct kmem_cache_node {
 	spinlock_t list_lock;	/* Protect partial list and nr_partial */
@@ -58,6 +59,8 @@ struct kmem_cache {
  */
 #define KMALLOC_SHIFT_LOW 3
 
+#define KMALLOC_MIN_SIZE (1UL << KMALLOC_SHIFT_LOW)
+
 /*
  * We keep the general caches in an array of slab caches that are used for
  * 2^x bytes of allocations.
@@ -65,56 +68,36 @@ struct kmem_cache {
 extern struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_HIGH + 1];
 
 /*
- * Sorry that the following has to be that ugly but some versions of GCC
- * have trouble with constant propagation and loops.
+ * Determine the kmalloc array index given the object size.
+ *
+ * Return -1 if the object size is not supported.
  */
 static inline int kmalloc_index(size_t size)
 {
 	/*
-	 * We should return 0 if size == 0 but we use the smallest object
-	 * here for SLAB legacy reasons.
+	 * We should return 0 if size == 0 (which would result in the
+	 * kmalloc caller to get NULL) but we use the smallest object
+	 * here for legacy reasons. Just issue a warning so that
+	 * we can discover locations where we do 0 sized allocations.
 	 */
 	WARN_ON_ONCE(size == 0);
 
 	if (size > KMALLOC_MAX_SIZE)
 		return -1;
 
+	if (size <= KMALLOC_MIN_SIZE)
+		return KMALLOC_SHIFT_LOW;
+
+	/*
+	 * We map the non power of two slabs to the unused
+	 * log2 values in the kmalloc array.
+	 */
 	if (size > 64 && size <= 96)
 		return 1;
 	if (size > 128 && size <= 192)
 		return 2;
-	if (size <=          8) return 3;
-	if (size <=         16) return 4;
-	if (size <=         32) return 5;
-	if (size <=         64) return 6;
-	if (size <=        128) return 7;
-	if (size <=        256) return 8;
-	if (size <=        512) return 9;
-	if (size <=       1024) return 10;
-	if (size <=   2 * 1024) return 11;
-	if (size <=   4 * 1024) return 12;
-	if (size <=   8 * 1024) return 13;
-	if (size <=  16 * 1024) return 14;
-	if (size <=  32 * 1024) return 15;
-	if (size <=  64 * 1024) return 16;
-	if (size <= 128 * 1024) return 17;
-	if (size <= 256 * 1024) return 18;
-	if (size <=  512 * 1024) return 19;
-	if (size <= 1024 * 1024) return 20;
-	if (size <=  2 * 1024 * 1024) return 21;
-	if (size <=  4 * 1024 * 1024) return 22;
-	if (size <=  8 * 1024 * 1024) return 23;
-	if (size <= 16 * 1024 * 1024) return 24;
-	if (size <= 32 * 1024 * 1024) return 25;
-	return -1;
 
-/*
- * What we really wanted to do and cannot do because of compiler issues is:
- *	int i;
- *	for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++)
- *		if (size <= (1 << i))
- *			return i;
- */
+	return ilog2(size - 1) + 1;
 }
 
 /*
@@ -131,18 +114,9 @@ static inline struct kmem_cache *kmalloc
 		return NULL;
 
 	/*
-	 * This function only gets expanded if __builtin_constant_p(size), so
-	 * testing it here shouldn't be needed.  But some versions of gcc need
-	 * help.
+	 * If this triggers then the amount of memory requested was too large.
 	 */
-	if (__builtin_constant_p(size) && index < 0) {
-		/*
-		 * Generate a link failure. Would be great if we could
-		 * do something to stop the compile here.
-		 */
-		extern void __kmalloc_size_too_large(void);
-		__kmalloc_size_too_large();
-	}
+	BUG_ON(index < 0);
 	return &kmalloc_caches[index];
 }
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Pekka Enberg]

On 5/21/07, Christoph Lameter <clameter@sgi.com> wrote:
> I finally found a way to get rid of the nasty list of comparisions in
> slub_def.h. ilog2 seems to work right for constants.

Nice cleanup Christoph! Looks good to me.

Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Andrew Morton]

On Mon, 21 May 2007 12:51:47 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> I finally found a way to get rid of the nasty list of comparisions in
> slub_def.h. ilog2 seems to work right for constants.

This caused test.kernel.org's power4 build to blow up:

http://test.kernel.org/abat/93315/debug/test.log.0

fs/built-in.o(.text+0x148420): In function `.CalcNTLMv2_partial_mac_key':
: undefined reference to `.____ilog2_NaN'

it doesn't happen on my power4 toolchain so I expect it's some artifact
due to test.k.o's tendency to use crufty old toolchains.

arguably it's a bug in ilog2, dunno.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Christoph Lameter]

On Wed, 6 Jun 2007, Andrew Morton wrote:

> This caused test.kernel.org's power4 build to blow up:
> 
> http://test.kernel.org/abat/93315/debug/test.log.0
> 
> fs/built-in.o(.text+0x148420): In function `.CalcNTLMv2_partial_mac_key':
> : undefined reference to `.____ilog2_NaN'

Hmmm... Weird message that does not allow too much analysis.
The __ilog2_NaN comes about if 0 or a negative number is passed to ilog. 
There is no way for that to happen since we check for KMALLOC_MIN_SIZE 
and KMALLOC_MAX_SIZE in kmalloc_index() and an unsigned value is used.

There is also nothing special in CalcNTLMv2_partial_mac_key(). Two 
kmallocs of 33 bytes and 132 bytes each.

Buggy compiler (too much stress on constant folding)? Or hardware? Can we 
rerun the test?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Andrew Morton]

On Wed, 6 Jun 2007 11:36:07 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> On Wed, 6 Jun 2007, Andrew Morton wrote:
> 
> > This caused test.kernel.org's power4 build to blow up:
> > 
> > http://test.kernel.org/abat/93315/debug/test.log.0
> > 
> > fs/built-in.o(.text+0x148420): In function `.CalcNTLMv2_partial_mac_key':
> > : undefined reference to `.____ilog2_NaN'
> 
> Hmmm... Weird message that does not allow too much analysis.
> The __ilog2_NaN comes about if 0 or a negative number is passed to ilog. 
> There is no way for that to happen since we check for KMALLOC_MIN_SIZE 
> and KMALLOC_MAX_SIZE in kmalloc_index() and an unsigned value is used.
> 
> There is also nothing special in CalcNTLMv2_partial_mac_key(). Two 
> kmallocs of 33 bytes and 132 bytes each.

Yes, the code all looks OK.  I suspect this is another case of the compiler
failing to remove unreachable stuff.

> Buggy compiler (too much stress on constant folding)? Or hardware? Can we 
> rerun the test?

It happened multiple times:
http://test.kernel.org/functional/pSeries-101_2.html

I'm sure there's a way of extracting the compiler version out of
test.kernel.org but I can't see it there.  Andy, maybe we should toss a gcc
--version in there or something?


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Christoph Lameter]

On Wed, 6 Jun 2007, Andrew Morton wrote:

> > There is also nothing special in CalcNTLMv2_partial_mac_key(). Two 
> > kmallocs of 33 bytes and 132 bytes each.
> 
> Yes, the code all looks OK.  I suspect this is another case of the compiler
> failing to remove unreachable stuff.

Sigh.

The patch was already in 2.6.22-rc3-mm1. Why did the patch pass the 
testing during that release cycle?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Nish Aravamudan]

On 6/6/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 6 Jun 2007 11:36:07 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:
>
> > On Wed, 6 Jun 2007, Andrew Morton wrote:
> >
> > > This caused test.kernel.org's power4 build to blow up:
> > >
> > > http://test.kernel.org/abat/93315/debug/test.log.0
> > >
> > > fs/built-in.o(.text+0x148420): In function `.CalcNTLMv2_partial_mac_key':
> > > : undefined reference to `.____ilog2_NaN'
> >
> > Hmmm... Weird message that does not allow too much analysis.
> > The __ilog2_NaN comes about if 0 or a negative number is passed to ilog.
> > There is no way for that to happen since we check for KMALLOC_MIN_SIZE
> > and KMALLOC_MAX_SIZE in kmalloc_index() and an unsigned value is used.
> >
> > There is also nothing special in CalcNTLMv2_partial_mac_key(). Two
> > kmallocs of 33 bytes and 132 bytes each.
>
> Yes, the code all looks OK.  I suspect this is another case of the compiler
> failing to remove unreachable stuff.
>
> > Buggy compiler (too much stress on constant folding)? Or hardware? Can we
> > rerun the test?
>
> It happened multiple times:
> http://test.kernel.org/functional/pSeries-101_2.html
>
> I'm sure there's a way of extracting the compiler version out of
> test.kernel.org but I can't see it there.  Andy, maybe we should toss a gcc
> --version in there or something?

I went and looked at one of the GOOD jobs and acc'g to that, the gcc is

gcc version 3.3.3 (SuSE Linux)

(http://test.kernel.org/abat/93029/summary)

I agree, seems like it would be handy to spit that out somewhere nicer
and easier to get to. Maybe the machine links at the top should point
to a summary page which has a link to the .config, machine info, etc?
(more indirection, but may be ok).

Thanks,
Nish

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Andrew Morton]

On Wed, 6 Jun 2007 13:28:40 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> On Wed, 6 Jun 2007, Andrew Morton wrote:
> 
> > > There is also nothing special in CalcNTLMv2_partial_mac_key(). Two 
> > > kmallocs of 33 bytes and 132 bytes each.
> > 
> > Yes, the code all looks OK.  I suspect this is another case of the compiler
> > failing to remove unreachable stuff.
> 
> Sigh.
> 
> The patch was already in 2.6.22-rc3-mm1. Why did the patch pass the 
> testing during that release cycle?

Good question - don't know, sorry.

I tried to build gcc-3.3.3 the other day.  Would you believe that gcc-4.1.0
fails to compile gcc-3.3.3?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Martin Bligh]

Andrew Morton wrote:
> On Wed, 6 Jun 2007 13:28:40 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:
> 
>> On Wed, 6 Jun 2007, Andrew Morton wrote:
>>
>>>> There is also nothing special in CalcNTLMv2_partial_mac_key(). Two 
>>>> kmallocs of 33 bytes and 132 bytes each.
>>> Yes, the code all looks OK.  I suspect this is another case of the compiler
>>> failing to remove unreachable stuff.
>> Sigh.
>>
>> The patch was already in 2.6.22-rc3-mm1. Why did the patch pass the 
>> testing during that release cycle?
> 
> Good question - don't know, sorry.
> 
> I tried to build gcc-3.3.3 the other day.  Would you believe that gcc-4.1.0
> fails to compile gcc-3.3.3?

IIRC, the SUSE ones were customized anyway, so not sure that'd help you.
Might do though.

There should be a sysinfo directory that lists stuff like gcc version,
maybe it's not getting replicated to TKO though ... Nish or Andy,
any chance you can take a look at the original copy of one of those
jobs on the ABAT server?

I just fixed autotest, but I can't fix the old IBM code from here ;-)
Anything else that'd be particularly handy to dump all the time?
You can see what we're currently doing in the context of the diff
below.

Index: sysinfo.py
===================================================================
--- sysinfo.py  (revision 527)
+++ sysinfo.py  (working copy)
@@ -8,7 +8,7 @@
  files = ['/proc/pci', '/proc/meminfo', '/proc/slabinfo', '/proc/version',
         '/proc/cpuinfo', '/proc/cmdline']
  # commands = ['lshw']        # this causes problems triggering CDROM 
drives
-commands = ['uname -a', 'lspci -vvn']
+commands = ['uname -a', 'lspci -vvn', 'gcc --version']
  path = ['/usr/bin', '/bin']

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Christoph Lameter]

On Wed, 6 Jun 2007, Andrew Morton wrote:

> I tried to build gcc-3.3.3 the other day.  Would you believe that gcc-4.1.0
> fails to compile gcc-3.3.3?

Yes I tried building a gcc compiler for a special config a while back. 
After a few days I came to the firm conclusion that its not worth the 
time. Fortunately I found a group of guys that do it all for me and I get 
daily updates of their work.

clameter@schroedinger:~$ apt-cache search gcc
cpp - The GNU C preprocessor (cpp)
cpp-2.95 - The GNU C preprocessor
cpp-2.95-doc - Documentation for the GNU C preprocessor (cpp)
cpp-3.3 - The GNU C preprocessor
cpp-3.4 - The GNU C preprocessor
cpp-4.1 - The GNU C preprocessor
cpp-4.2 - The GNU C preprocessor
cpphs - Simplified cpp-a-like preprocessor for Haskell
emdebian-tools - emdebian crossbuilding tool set
g++-2.95 - The GNU C++ compiler
g++-3.4 - The GNU C++ compiler
g77 - The GNU Fortran 77 compiler
g77-2.95 - The GNU Fortran 77 compiler
g77-2.95-doc - Documentation for the GNU Fortran compiler (g77)
g77-3.4 - The GNU Fortran 77 compiler
gcc - The GNU C compiler
gcc-2.95 - The GNU C compiler
gcc-2.95-doc - Documentation for the GNU compilers (gcc, gobjc, g++)
gcc-3.3 - The GNU C compiler
gcc-3.3-base - The GNU Compiler Collection (base package)
gcc-3.4 - The GNU C compiler
gcc-3.4-base - The GNU Compiler Collection (base package)
gcc-4.1 - The GNU C compiler
gcc-4.1-base - The GNU Compiler Collection (base package)
gcc-4.1-locales - The GNU C compiler (native language support files)
gcc-4.1-source - Source of the GNU Compiler Collection
gcc-4.2 - The GNU C compiler
gcc-4.2-base - The GNU Compiler Collection (base package)
gcc-4.2-doc - Documentation for the GNU compilers (gcc, gobjc, g++)
gcc-4.2-locales - The GNU C compiler (native language support files)
gcc-4.2-multilib - The GNU C compiler (multilib files)
gcc-4.2-source - Source of the GNU Compiler Collection
gcc-avr - The GNU C compiler (cross compiler for avr)
gcc-m68hc1x - GNU C compiler for the Motorola 68HC11/12 processors
gcc272 - The GNU C compiler.
gcc272-docs - Documentation for the gcc compiler (gcc272).
gccxml - XML output extension to GCC
gcj - The GNU Java compiler
gcj-4.1 - The GNU compiler for Java(TM)
gcj-4.1-base - The GNU Compiler Collection (gcj base package)
gfortran - The GNU Fortran 95 compiler
gfortran-4.1 - The GNU Fortran 95 compiler
gfortran-4.2 - The GNU Fortran 95 compiler
gfortran-4.2-multilib - The GNU Fortran 95 compiler (multilib files)
ggcov - Graphical tool for displaying gcov test coverage data
gnat-4.1 - The GNU Ada compiler
gnat-4.1-base - The GNU Compiler Collection (gnat base package)
gobjc - The GNU Objective-C compiler
gobjc++ - The GNU Objective-C++ compiler
gobjc++-4.1 - The GNU Objective-C++ compiler
gobjc++-4.2 - The GNU Objective-C++ compiler
gobjc++-4.2-multilib - The GNU Objective-C++ compiler (multilib files)
gobjc-2.95 - The GNU Objective-C compiler
gobjc-4.1 - The GNU Objective-C compiler
gobjc-4.2 - The GNU Objective-C compiler
gobjc-4.2-multilib - The GNU Objective-C compiler (multilib files)
gpc - The GNU Pascal compiler
gpc-2.1-3.4 - The GNU Pascal compiler
gpc-2.1-3.4-doc - Documentation for the GNU Pascal compiler (gpc)
gpc-2.95 - The GNU Pascal compiler
gpc-2.95-doc - Documentation for the GNU Pascal compiler (gpc)
cpp-3.3-arm-linux-gnu - The GNU C preprocessor
cpp-3.3-ia64-linux-gnu - The GNU C preprocessor
cpp-3.3-m68k-linux-gnu - The GNU C preprocessor
cpp-3.3-mips-linux-gnu - The GNU C preprocessor
cpp-3.3-mipsel-linux-gnu - The GNU C preprocessor
cpp-3.3-powerpc-linux-gnu - The GNU C preprocessor
cpp-3.3-sparc-linux-gnu - The GNU C preprocessor
cpp-3.4-alpha-linux-gnu - The GNU C preprocessor
cpp-3.4-arm-linux-gnu - The GNU C preprocessor
cpp-3.4-ia64-linux-gnu - The GNU C preprocessor
cpp-3.4-m68k-linux-gnu - The GNU C preprocessor
cpp-3.4-mips-linux-gnu - The GNU C preprocessor
cpp-3.4-mipsel-linux-gnu - The GNU C preprocessor
cpp-3.4-powerpc-linux-gnu - The GNU C preprocessor
cpp-3.4-sparc-linux-gnu - The GNU C preprocessor
cpp-4.0-arm-linux-gnu - The GNU C preprocessor
cpp-4.0-ia64-linux-gnu - The GNU C preprocessor
cpp-4.0-mips-linux-gnu - The GNU C preprocessor
cpp-4.0-mipsel-linux-gnu - The GNU C preprocessor
cpp-4.0-powerpc-linux-gnu - The GNU C preprocessor
cpp-4.0-sparc-linux-gnu - The GNU C preprocessor
cpp-4.1-alpha-linux-gnu - The GNU C preprocessor
cpp-4.1-arm-linux-gnu - The GNU C preprocessor
cpp-4.1-ia64-linux-gnu - The GNU C preprocessor
cpp-4.1-m68k-linux-gnu - The GNU C preprocessor
cpp-4.1-mips-linux-gnu - The GNU C preprocessor
cpp-4.1-mipsel-linux-gnu - The GNU C preprocessor
cpp-4.1-powerpc-linux-gnu - The GNU C preprocessor
cpp-4.1-s390-linux-gnu - The GNU C preprocessor
cpp-4.1-sparc-linux-gnu - The GNU C preprocessor
g++-3.4-alpha-linux-gnu - The GNU C++ compiler
g++-3.4-arm-linux-gnu - The GNU C++ compiler
g++-3.4-ia64-linux-gnu - The GNU C++ compiler
g++-3.4-m68k-linux-gnu - The GNU C++ compiler
g++-3.4-mips-linux-gnu - The GNU C++ compiler
g++-3.4-mipsel-linux-gnu - The GNU C++ compiler
g++-3.4-powerpc-linux-gnu - The GNU C++ compiler
g++-3.4-sparc-linux-gnu - The GNU C++ compiler
gcc-3.3-alpha-linux-gnu - The GNU C compiler
gcc-3.3-arm-linux-gnu - The GNU C compiler
gcc-3.3-ia64-linux-gnu - The GNU C compiler
gcc-3.3-m68k-linux-gnu - The GNU C compiler
gcc-3.3-mips-linux-gnu - The GNU C compiler
gcc-3.3-mipsel-linux-gnu - The GNU C compiler
gcc-3.3-powerpc-linux-gnu - The GNU C compiler
gcc-3.3-sparc-linux-gnu - The GNU C compiler
gcc-3.4-alpha-linux-gnu - The GNU C compiler
gcc-3.4-arm-linux-gnu - The GNU C compiler
gcc-3.4-ia64-linux-gnu - The GNU C compiler
gcc-3.4-m68k-linux-gnu - The GNU C compiler
gcc-3.4-mips-linux-gnu - The GNU C compiler
gcc-3.4-mipsel-linux-gnu - The GNU C compiler
gcc-3.4-powerpc-linux-gnu - The GNU C compiler
gcc-3.4-sparc-linux-gnu - The GNU C compiler
gcc-4.0-arm-linux-gnu - The GNU C compiler
gcc-4.0-arm-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.0-ia64-linux-gnu - The GNU C compiler
gcc-4.0-ia64-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.0-m68k-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.0-mips-linux-gnu - The GNU C compiler
gcc-4.0-mips-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.0-mipsel-linux-gnu - The GNU C compiler
gcc-4.0-mipsel-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.0-powerpc-linux-gnu - The GNU C compiler
gcc-4.0-powerpc-linux-gnu-base - The GNU Compiler Collection (base 
package)
gcc-4.0-sparc-linux-gnu - The GNU C compiler
gcc-4.0-sparc-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.1-alpha-linux-gnu - The GNU C compiler
gcc-4.1-alpha-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.1-arm-linux-gnu - The GNU C compiler
gcc-4.1-arm-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.1-ia64-linux-gnu - The GNU C compiler
gcc-4.1-ia64-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.1-m68k-linux-gnu - The GNU C compiler
gcc-4.1-m68k-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.1-mips-linux-gnu - The GNU C compiler
gcc-4.1-mips-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.1-mipsel-linux-gnu - The GNU C compiler
gcc-4.1-mipsel-linux-gnu-base - The GNU Compiler Collection (base package)
gcc-4.1-powerpc-linux-gnu - The GNU C compiler
gcc-4.1-powerpc-linux-gnu-base - The GNU Compiler Collection (base 
package)
gcc-4.1-s390-linux-gnu - The GNU C compiler
gcc-4.1-sparc-linux-gnu - The GNU C compiler
gcc-4.1-sparc-linux-gnu-base - The GNU Compiler Collection (base package)
lib64gcc1-powerpc-cross - GCC support library (64bit)
lib64gcc1-s390-cross - GCC support library (64bit)
lib64gcc1-sparc-cross - GCC support library (64bit)
libgcc1-alpha-cross - GCC support library
libgcc1-arm-cross - GCC support library
libgcc1-ia64-cross - GCC support library
libgcc1-m68k-cross - GCC support library
libgcc1-mips-cross - GCC support library
libgcc1-mipsel-cross - GCC support library
libgcc1-powerpc-cross - GCC support library
libgcc1-s390-cross - GCC support library
libgcc1-sparc-cross - GCC support library
libgcc2-m68k-cross - GCC support library
libgcc4-hppa-cross - GCC support library (for cross-compiling)
cpp-4.0 - The GNU C preprocessor
libgcj6-common - Java runtime library for use with gcj (jar files)
gcc-4.0 - The GNU C compiler
libgcj6 - Java runtime library for use with gcj
gcc-4.0-base - The GNU Compiler Collection (base package)
gcj-4.0-base - The GNU Compiler Collection (gcj base package)
toolchain-source - The GNU binutils and gcc source code


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Christoph Lameter]

On Wed, 6 Jun 2007, Martin Bligh wrote:

> > I tried to build gcc-3.3.3 the other day.  Would you believe that gcc-4.1.0
> > fails to compile gcc-3.3.3?
> 
> IIRC, the SUSE ones were customized anyway, so not sure that'd help you.
> Might do though.

Tried building with gcc-3.3

clameter@schroedinger:~/software/slub$ powerpc-linux-gnu-gcc --version
powerpc-linux-gnu-gcc (GCC) 3.3.6 (Debian 1:3.3.6-15)

but cell_defconfig and pseries_defconfig fail to build straight out.
This is what happens with pseries_defconfig:

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CC      arch/powerpc/kernel/asm-offsets.s
In file included from include/asm/mmu.h:7,
                 from include/asm/lppaca.h:32,
                 from include/asm/paca.h:20,
                 from include/asm/hw_irq.h:17,
                 from include/asm/system.h:9,
                 from include/linux/list.h:9,
                 from include/linux/signal.h:8,
                 from arch/powerpc/kernel/asm-offsets.c:16:
include/asm/mmu-hash64.h: In function `hpte_encode_r':
include/asm/mmu-hash64.h:216: warning: integer constant is too large for 
"unsigned long" type
include/asm/mmu-hash64.h: In function `hpt_hash':
include/asm/mmu-hash64.h:231: warning: integer constant is too large for 
"unsigned long" type
include/asm/mmu-hash64.h: In function `vsid_scramble':
include/asm/mmu-hash64.h:387: warning: right shift count >= width of type
include/asm/mmu-hash64.h:387: warning: left shift count >= width of type
include/asm/mmu-hash64.h:388: warning: right shift count >= width of type
include/asm/mmu-hash64.h:388: warning: left shift count >= width of type
include/asm/mmu-hash64.h: In function `get_kernel_vsid':
include/asm/mmu-hash64.h:395: error: `SID_SHIFT' undeclared (first use in 
this function)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Andrew Morton]

On Wed, 6 Jun 2007 13:52:01 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> On Wed, 6 Jun 2007, Martin Bligh wrote:
> 
> > > I tried to build gcc-3.3.3 the other day.  Would you believe that gcc-4.1.0
> > > fails to compile gcc-3.3.3?
> > 
> > IIRC, the SUSE ones were customized anyway, so not sure that'd help you.
> > Might do though.
> 
> Tried building with gcc-3.3
> 
> clameter@schroedinger:~/software/slub$ powerpc-linux-gnu-gcc --version
> powerpc-linux-gnu-gcc (GCC) 3.3.6 (Debian 1:3.3.6-15)
> 
> but cell_defconfig and pseries_defconfig fail to build straight out.
> This is what happens with pseries_defconfig:
> 
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   CC      arch/powerpc/kernel/asm-offsets.s
> In file included from include/asm/mmu.h:7,
>                  from include/asm/lppaca.h:32,
>                  from include/asm/paca.h:20,
>                  from include/asm/hw_irq.h:17,
>                  from include/asm/system.h:9,
>                  from include/linux/list.h:9,
>                  from include/linux/signal.h:8,
>                  from arch/powerpc/kernel/asm-offsets.c:16:
> include/asm/mmu-hash64.h: In function `hpte_encode_r':
> include/asm/mmu-hash64.h:216: warning: integer constant is too large for 
> "unsigned long" type
> include/asm/mmu-hash64.h: In function `hpt_hash':
> include/asm/mmu-hash64.h:231: warning: integer constant is too large for 
> "unsigned long" type
> include/asm/mmu-hash64.h: In function `vsid_scramble':
> include/asm/mmu-hash64.h:387: warning: right shift count >= width of type
> include/asm/mmu-hash64.h:387: warning: left shift count >= width of type
> include/asm/mmu-hash64.h:388: warning: right shift count >= width of type
> include/asm/mmu-hash64.h:388: warning: left shift count >= width of type
> include/asm/mmu-hash64.h: In function `get_kernel_vsid':
> include/asm/mmu-hash64.h:395: error: `SID_SHIFT' undeclared (first use in 
> this function)

<recovers from three-hour outage, caused by both ends of ethernet cable
plugged into the same switch, two switches away.  Offspring suspected.>

Did you try starting from the test.kernel.org config? 
http://test.kernel.org/abat/93412/build/dotconfig

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Nish Aravamudan]

On 6/6/07, Martin Bligh <mbligh@mbligh.org> wrote:
> Andrew Morton wrote:
> > On Wed, 6 Jun 2007 13:28:40 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:
> >
> >> On Wed, 6 Jun 2007, Andrew Morton wrote:
> >>
> >>>> There is also nothing special in CalcNTLMv2_partial_mac_key(). Two
> >>>> kmallocs of 33 bytes and 132 bytes each.
> >>> Yes, the code all looks OK.  I suspect this is another case of the compiler
> >>> failing to remove unreachable stuff.
> >> Sigh.
> >>
> >> The patch was already in 2.6.22-rc3-mm1. Why did the patch pass the
> >> testing during that release cycle?
> >
> > Good question - don't know, sorry.
> >
> > I tried to build gcc-3.3.3 the other day.  Would you believe that gcc-4.1.0
> > fails to compile gcc-3.3.3?
>
> IIRC, the SUSE ones were customized anyway, so not sure that'd help you.
> Might do though.
>
> There should be a sysinfo directory that lists stuff like gcc version,
> maybe it's not getting replicated to TKO though ... Nish or Andy,
> any chance you can take a look at the original copy of one of those
> jobs on the ABAT server?

Looked at this one --  I could have sworn there was a sysinfo
directory at some point too. But I don't see it on the ABAT job. There
is a compiler.ver, and it contains what I pasted before essentially:

Reading specs from /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--host=powerpc-suse-linux --build=powerpc-suse-linux
--target=powerpc-suse-linux --enable-targets=powerpc64-suse-linux
--enable-biarch
Thread model: posix
gcc version 3.3.3 (SuSE Linux)

Thanks,
Nish

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Christoph Lameter]

On Wed, 6 Jun 2007, Andrew Morton wrote:

> Did you try starting from the test.kernel.org config? 
> http://test.kernel.org/abat/93412/build/dotconfig

Ok used that one but same result.

There must be something trivial that I do not do right. The compile does 
not get that this is a 64 bit compile. Maybe I cannot do a 64 bit compile 
on a 32 bit system (this is i386)?

clameter@schroedinger:~/software/slub$ cat /usr/local/bin/make_powerpc
make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- $*

clameter@schroedinger:~/software/slub$ make_powerpc all
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CC      arch/powerpc/kernel/asm-offsets.s
In file included from include/asm/mmu.h:7,
                 from include/asm/lppaca.h:32,
                 from include/asm/paca.h:20,
                 from include/asm/hw_irq.h:17,
                 from include/asm/system.h:9,
                 from include/linux/list.h:9,
                 from include/linux/signal.h:8,
                 from arch/powerpc/kernel/asm-offsets.c:16:
include/asm/mmu-hash64.h: In function `hpte_encode_r':
include/asm/mmu-hash64.h:216: warning: integer constant is too large for 
"unsigned long" type
include/asm/mmu-hash64.h: In function `hpt_hash':
include/asm/mmu-hash64.h:231: warning: integer constant is too large for 
"unsign

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Nish Aravamudan]

On 6/6/07, Christoph Lameter <clameter@sgi.com> wrote:
> On Wed, 6 Jun 2007, Andrew Morton wrote:
>
> > Did you try starting from the test.kernel.org config?
> > http://test.kernel.org/abat/93412/build/dotconfig
>
> Ok used that one but same result.
>
> There must be something trivial that I do not do right. The compile does
> not get that this is a 64 bit compile. Maybe I cannot do a 64 bit compile
> on a 32 bit system (this is i386)?
>
> clameter@schroedinger:~/software/slub$ cat /usr/local/bin/make_powerpc
> make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- $*

Hrm, what does V=1 say? Perhaps you need to somehow pass in -m64 or
something, if it's a biarch compiler (ppc32 and ppc64)?

Thanks,
Nish

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Christoph Lameter]

On Wed, 6 Jun 2007, Nish Aravamudan wrote:

> > clameter@schroedinger:~/software/slub$ cat /usr/local/bin/make_powerpc
> > make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- $*
> 
> Hrm, what does V=1 say? Perhaps you need to somehow pass in -m64 or
> something, if it's a biarch compiler (ppc32 and ppc64)?

No idea if that is the case but should the kernel not automagically adjust 
to that?

V=1 does not add additional output.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Andy Whitcroft]

Martin Bligh wrote:
> Andrew Morton wrote:
>> On Wed, 6 Jun 2007 13:28:40 -0700 (PDT) Christoph Lameter
>> <clameter@sgi.com> wrote:
>>
>>> On Wed, 6 Jun 2007, Andrew Morton wrote:
>>>
>>>>> There is also nothing special in CalcNTLMv2_partial_mac_key(). Two
>>>>> kmallocs of 33 bytes and 132 bytes each.
>>>> Yes, the code all looks OK.  I suspect this is another case of the
>>>> compiler
>>>> failing to remove unreachable stuff.
>>> Sigh.
>>>
>>> The patch was already in 2.6.22-rc3-mm1. Why did the patch pass the
>>> testing during that release cycle?
>>
>> Good question - don't know, sorry.
>>
>> I tried to build gcc-3.3.3 the other day.  Would you believe that
>> gcc-4.1.0
>> fails to compile gcc-3.3.3?
> 
> IIRC, the SUSE ones were customized anyway, so not sure that'd help you.
> Might do though.
> 
> There should be a sysinfo directory that lists stuff like gcc version,
> maybe it's not getting replicated to TKO though ... Nish or Andy,
> any chance you can take a look at the original copy of one of those
> jobs on the ABAT server?
> 
> I just fixed autotest, but I can't fix the old IBM code from here ;-)
> Anything else that'd be particularly handy to dump all the time?
> You can see what we're currently doing in the context of the diff
> below.
> 
> Index: sysinfo.py
> ===================================================================
> --- sysinfo.py  (revision 527)
> +++ sysinfo.py  (working copy)
> @@ -8,7 +8,7 @@
>  files = ['/proc/pci', '/proc/meminfo', '/proc/slabinfo', '/proc/version',
>         '/proc/cpuinfo', '/proc/cmdline']
>  # commands = ['lshw']        # this causes problems triggering CDROM
> drives
> -commands = ['uname -a', 'lspci -vvn']
> +commands = ['uname -a', 'lspci -vvn', 'gcc --version']
>  path = ['/usr/bin', '/bin']


Yep this is something we keep in the job, but apparently something we
don't push out to you.

Reading specs from /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--host=powerpc-suse-linux --build=powerpc-suse-linux
--target=powerpc-suse-linux --enable-targets=powerpc64-suse-linux
--enable-biarch
Thread model: posix
gcc version 3.3.3 (SuSE Linux)

-apw

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Andy Whitcroft]

Nish Aravamudan wrote:
> On 6/6/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Wed, 6 Jun 2007 11:36:07 -0700 (PDT) Christoph Lameter
>> <clameter@sgi.com> wrote:
>>
>> > On Wed, 6 Jun 2007, Andrew Morton wrote:
>> >
>> > > This caused test.kernel.org's power4 build to blow up:
>> > >
>> > > http://test.kernel.org/abat/93315/debug/test.log.0
>> > >
>> > > fs/built-in.o(.text+0x148420): In function
>> `.CalcNTLMv2_partial_mac_key':
>> > > : undefined reference to `.____ilog2_NaN'
>> >
>> > Hmmm... Weird message that does not allow too much analysis.
>> > The __ilog2_NaN comes about if 0 or a negative number is passed to
>> ilog.
>> > There is no way for that to happen since we check for KMALLOC_MIN_SIZE
>> > and KMALLOC_MAX_SIZE in kmalloc_index() and an unsigned value is used.
>> >
>> > There is also nothing special in CalcNTLMv2_partial_mac_key(). Two
>> > kmallocs of 33 bytes and 132 bytes each.
>>
>> Yes, the code all looks OK.  I suspect this is another case of the
>> compiler
>> failing to remove unreachable stuff.
>>
>> > Buggy compiler (too much stress on constant folding)? Or hardware?
>> Can we
>> > rerun the test?
>>
>> It happened multiple times:
>> http://test.kernel.org/functional/pSeries-101_2.html
>>
>> I'm sure there's a way of extracting the compiler version out of
>> test.kernel.org but I can't see it there.  Andy, maybe we should toss
>> a gcc
>> --version in there or something?
> 
> I went and looked at one of the GOOD jobs and acc'g to that, the gcc is
> 
> gcc version 3.3.3 (SuSE Linux)
> 
> (http://test.kernel.org/abat/93029/summary)
> 
> I agree, seems like it would be handy to spit that out somewhere nicer
> and easier to get to. Maybe the machine links at the top should point
> to a summary page which has a link to the .config, machine info, etc?
> (more indirection, but may be ok).

They probably should be replicated with the job as the machine may
change compiler at some time in its life.  If for no other reason that
there should be a break in the kernbench graph if it does ... :)

-apw

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Use ilog2 instead of series of constant comparisons.

[Andy Whitcroft]

Andy Whitcroft wrote:
> Nish Aravamudan wrote:
>> On 6/6/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>>> On Wed, 6 Jun 2007 11:36:07 -0700 (PDT) Christoph Lameter
>>> <clameter@sgi.com> wrote:
>>>
>>>> On Wed, 6 Jun 2007, Andrew Morton wrote:
>>>>
>>>>> This caused test.kernel.org's power4 build to blow up:
>>>>>
>>>>> http://test.kernel.org/abat/93315/debug/test.log.0
>>>>>
>>>>> fs/built-in.o(.text+0x148420): In function
>>> `.CalcNTLMv2_partial_mac_key':
>>>>> : undefined reference to `.____ilog2_NaN'
>>>> Hmmm... Weird message that does not allow too much analysis.
>>>> The __ilog2_NaN comes about if 0 or a negative number is passed to
>>> ilog.
>>>> There is no way for that to happen since we check for KMALLOC_MIN_SIZE
>>>> and KMALLOC_MAX_SIZE in kmalloc_index() and an unsigned value is used.
>>>>
>>>> There is also nothing special in CalcNTLMv2_partial_mac_key(). Two
>>>> kmallocs of 33 bytes and 132 bytes each.
>>> Yes, the code all looks OK.  I suspect this is another case of the
>>> compiler
>>> failing to remove unreachable stuff.
>>>
>>>> Buggy compiler (too much stress on constant folding)? Or hardware?
>>> Can we
>>>> rerun the test?
>>> It happened multiple times:
>>> http://test.kernel.org/functional/pSeries-101_2.html
>>>
>>> I'm sure there's a way of extracting the compiler version out of
>>> test.kernel.org but I can't see it there.  Andy, maybe we should toss
>>> a gcc
>>> --version in there or something?
>> I went and looked at one of the GOOD jobs and acc'g to that, the gcc is
>>
>> gcc version 3.3.3 (SuSE Linux)
>>
>> (http://test.kernel.org/abat/93029/summary)
>>
>> I agree, seems like it would be handy to spit that out somewhere nicer
>> and easier to get to. Maybe the machine links at the top should point
>> to a summary page which has a link to the .config, machine info, etc?
>> (more indirection, but may be ok).
> 
> They probably should be replicated with the job as the machine may
> change compiler at some time in its life.  If for no other reason that
> there should be a break in the kernbench graph if it does ... :)

Ok, the compiler.ver file should be replicated out with new jobs now and
can be found with the dotconfig file in the build directory.

-apw

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>