Re: [rfc] SLQB: YASA

[Nick Piggin]

On Tue, Apr 08, 2008 at 03:51:42PM -0300, Luiz Fernando N. Capitulino wrote:
> Em Tue, 8 Apr 2008 13:57:17 +0200
> Nick Piggin <npiggin@xxxxxxx> escreveu:
> 
> | Here is my more working version of SLQB. 
> | 
> | Was experimenting with a couple of different ways to do remote freeing,
> | but it is really hard to tune properly without having "real" workloads,
> | due to cache effects.
> | 
> | Anyway, same comments apply. Patch is against mainline.
> 
>  I get the following error when compiling without CONFIG_SMP
> 
> """
> In file included from include/linux/rcupdate.h:52,
>                  from include/linux/slqb_def.h:15,
>                  from include/linux/slab.h:121,
>                  from include/asm/pgtable_32.h:22,
>                  from include/asm/pgtable.h:241,
>                  from include/linux/mm.h:40,
>                  from arch/x86/kernel/pci-dma_32.c:12:
> include/linux/percpu.h: In function '__percpu_alloc_mask':
> include/linux/percpu.h:106: error: implicit declaration of function 'kzalloc'
> include/linux/percpu.h:106: warning: return makes pointer from integer without a cast
> In file included from include/asm/pgtable_32.h:22,
>                  from include/asm/pgtable.h:241,
>                  from include/linux/mm.h:40,
>                  from arch/x86/kernel/pci-dma_32.c:12:
> include/linux/slab.h: At top level:
> include/linux/slab.h:272: error: conflicting types for 'kzalloc'
> include/linux/percpu.h:106: error: previous implicit declaration of 'kzalloc' was here
> ICECC[27645] 15:49:30: Compiled on XXXXXXXX
> make[1]: *** [arch/x86/kernel/pci-dma_32.o] Error 1
> make: *** [arch/x86/kernel] Error 2
> 
> """
> 
>  Could not figure out what the problem is.

Hmm, it seems like some kind of recursive dep, but somehow it goes away
with SMP, so it must be fixable... I'll take a further look.

 
>  Regarding performance tests, I saw that Christoph has some
> interesting test modules in his git repository. Do you think it's
> worth to run them?

I have tried some of them, yes. Performance comparisons vary depending on
machine and workload, but I'd say it is mostly competitive. But those
tests are quite basic and are very far from real world situations. They
are very good for some cases showing where you might have a problem, but
not so useful when comparing 2 different allocators.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/