build error: sparsemem + SLOB

build error: sparsemem + SLOB

[Randy Dunlap]

  LD      .tmp_vmlinux1
mm/built-in.o: In function `sparse_index_init':
sparse.c:(.text.sparse_index_init+0x19): undefined reference to `slab_is_available'
make: *** [.tmp_vmlinux1] Error 1


mm/sparse.c: line 35 uses slab_is_available() but SLAB=n, SLOB=y.

---
~Randy
full config: http://oss.oracle.com/~rdunlap/configs/config-slob-sparse
(a randconfig)

--
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>

[PATCH]Re: build error: sparsemem + SLOB

[Yasunori Goto]

>   LD      .tmp_vmlinux1
> mm/built-in.o: In function `sparse_index_init':
> sparse.c:(.text.sparse_index_init+0x19): undefined reference to `slab_is_available'
> make: *** [.tmp_vmlinux1] Error 1
> 
> 
> mm/sparse.c: line 35 uses slab_is_available() but SLAB=n, SLOB=y.


Hmm.
To be honest, I don't know that embedded people would like to use sparsemem.
mem_section[] array might be too big for them.
But, they may expect reduce power consumption of memory by memory hotplug.

Anyway, this is fix.

------------
This patch is to fix compile error when SLOB is on with sparsemem.

  LD      .tmp_vmlinux1
mm/built-in.o: In function `sparse_index_init':
sparse.c:(.text.sparse_index_init+0x19): undefined reference to `slab_is_available'
make: *** [.tmp_vmlinux1] Error 1

mm/sparse.c: line 35 uses slab_is_available() but SLAB=n, SLOB=y.

This patch is for 2.6.19-rc5-mm2.


Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>

------------
 include/linux/slab.h |    9 +++++++++
 mm/slob.c            |    4 ++++
 mm/sparse.c          |    2 +-
 3 files changed, 14 insertions(+), 1 deletion(-)

Index: 19-rc5-mm2/include/linux/slab.h
===================================================================
--- 19-rc5-mm2.orig/include/linux/slab.h	2006-11-17 15:21:10.000000000 +0900
+++ 19-rc5-mm2/include/linux/slab.h	2006-11-20 19:07:20.000000000 +0900
@@ -210,6 +210,8 @@ static inline void *kcalloc(size_t n, si
 	return kzalloc(n * size, flags);
 }
 
+#define kmem_is_available() slab_is_available()
+
 extern void kfree(const void *);
 extern unsigned int ksize(const void *);
 extern int slab_is_available(void);
@@ -260,6 +262,13 @@ extern void kmem_set_shrinker(kmem_cache
 #else /* CONFIG_SLOB */
 
 /* SLOB allocator routines */
+extern int slob_initialized;
+
+#define kmem_is_available() slob_is_available()
+static inline int slob_is_available(void)
+{
+	return slob_initialized;
+}
 
 void kmem_cache_init(void);
 struct kmem_cache *kmem_cache_create(const char *c, size_t, size_t,
Index: 19-rc5-mm2/mm/slob.c
===================================================================
--- 19-rc5-mm2.orig/mm/slob.c	2006-11-17 15:20:47.000000000 +0900
+++ 19-rc5-mm2/mm/slob.c	2006-11-20 18:37:10.000000000 +0900
@@ -61,6 +61,8 @@ static DEFINE_SPINLOCK(block_lock);
 
 static void slob_free(void *b, int size);
 
+int slob_initialized= 0;
+
 static void *slob_alloc(size_t size, gfp_t gfp, int align)
 {
 	slob_t *prev, *cur, *aligned = 0;
@@ -337,4 +339,6 @@ void kmem_cache_init(void)
 		free_page((unsigned long)p);
 
 	mod_timer(&slob_timer, jiffies + HZ);
+	slob_initialized = 1;
+
 }
Index: 19-rc5-mm2/mm/sparse.c
===================================================================
--- 19-rc5-mm2.orig/mm/sparse.c	2006-11-17 15:21:10.000000000 +0900
+++ 19-rc5-mm2/mm/sparse.c	2006-11-20 16:20:56.000000000 +0900
@@ -50,7 +50,7 @@ static struct mem_section *sparse_index_
 	unsigned long array_size = SECTIONS_PER_ROOT *
 				   sizeof(struct mem_section);
 
-	if (slab_is_available())
+	if (kmem_is_available())
 		section = kmalloc_node(array_size, GFP_KERNEL, nid);
 	else
 		section = alloc_bootmem_node(NODE_DATA(nid), array_size);


-- 
Yasunori Goto 


--
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: [PATCH]Re: build error: sparsemem + SLOB

[Randy Dunlap]

Yasunori Goto wrote:
>>   LD      .tmp_vmlinux1
>> mm/built-in.o: In function `sparse_index_init':
>> sparse.c:(.text.sparse_index_init+0x19): undefined reference to `slab_is_available'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>>
>> mm/sparse.c: line 35 uses slab_is_available() but SLAB=n, SLOB=y.
> 
> 
> Hmm.
> To be honest, I don't know that embedded people would like to use sparsemem.
> mem_section[] array might be too big for them.
> But, they may expect reduce power consumption of memory by memory hotplug.
> 
> Anyway, this is fix.

Acked-by: Randy Dunlap <randy.dunlap@oracle.com>

> ------------
> This patch is to fix compile error when SLOB is on with sparsemem.
> 
>   LD      .tmp_vmlinux1
> mm/built-in.o: In function `sparse_index_init':
> sparse.c:(.text.sparse_index_init+0x19): undefined reference to `slab_is_available'
> make: *** [.tmp_vmlinux1] Error 1
> 
> mm/sparse.c: line 35 uses slab_is_available() but SLAB=n, SLOB=y.
> 
> This patch is for 2.6.19-rc5-mm2.
> 
> 
> Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
> 
> ------------
>  include/linux/slab.h |    9 +++++++++
>  mm/slob.c            |    4 ++++
>  mm/sparse.c          |    2 +-
>  3 files changed, 14 insertions(+), 1 deletion(-)
> 
> Index: 19-rc5-mm2/include/linux/slab.h
> ===================================================================
> --- 19-rc5-mm2.orig/include/linux/slab.h	2006-11-17 15:21:10.000000000 +0900
> +++ 19-rc5-mm2/include/linux/slab.h	2006-11-20 19:07:20.000000000 +0900
> @@ -210,6 +210,8 @@ static inline void *kcalloc(size_t n, si
>  	return kzalloc(n * size, flags);
>  }
>  
> +#define kmem_is_available() slab_is_available()
> +
>  extern void kfree(const void *);
>  extern unsigned int ksize(const void *);
>  extern int slab_is_available(void);
> @@ -260,6 +262,13 @@ extern void kmem_set_shrinker(kmem_cache
>  #else /* CONFIG_SLOB */
>  
>  /* SLOB allocator routines */
> +extern int slob_initialized;
> +
> +#define kmem_is_available() slob_is_available()
> +static inline int slob_is_available(void)
> +{
> +	return slob_initialized;
> +}
>  
>  void kmem_cache_init(void);
>  struct kmem_cache *kmem_cache_create(const char *c, size_t, size_t,
> Index: 19-rc5-mm2/mm/slob.c
> ===================================================================
> --- 19-rc5-mm2.orig/mm/slob.c	2006-11-17 15:20:47.000000000 +0900
> +++ 19-rc5-mm2/mm/slob.c	2006-11-20 18:37:10.000000000 +0900
> @@ -61,6 +61,8 @@ static DEFINE_SPINLOCK(block_lock);
>  
>  static void slob_free(void *b, int size);
>  
> +int slob_initialized= 0;
> +
>  static void *slob_alloc(size_t size, gfp_t gfp, int align)
>  {
>  	slob_t *prev, *cur, *aligned = 0;
> @@ -337,4 +339,6 @@ void kmem_cache_init(void)
>  		free_page((unsigned long)p);
>  
>  	mod_timer(&slob_timer, jiffies + HZ);
> +	slob_initialized = 1;
> +
>  }
> Index: 19-rc5-mm2/mm/sparse.c
> ===================================================================
> --- 19-rc5-mm2.orig/mm/sparse.c	2006-11-17 15:21:10.000000000 +0900
> +++ 19-rc5-mm2/mm/sparse.c	2006-11-20 16:20:56.000000000 +0900
> @@ -50,7 +50,7 @@ static struct mem_section *sparse_index_
>  	unsigned long array_size = SECTIONS_PER_ROOT *
>  				   sizeof(struct mem_section);
>  
> -	if (slab_is_available())
> +	if (kmem_is_available())
>  		section = kmalloc_node(array_size, GFP_KERNEL, nid);
>  	else
>  		section = alloc_bootmem_node(NODE_DATA(nid), array_size);
> 
> 


-- 
~Randy

--
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: build error: sparsemem + SLOB

[Christoph Lameter]

On Sun, 19 Nov 2006, Randy Dunlap wrote:

> mm/sparse.c: line 35 uses slab_is_available() but SLAB=n, SLOB=y.

I wonder if its worth bothering about SLOB?

As far as I can tell SLOB is fundamentally racy since it does not support 
SLAB_DESTROY_BY_RCU correctly. F.e. The constructor for the anon_vma will 
be called on alloc without regard for RCU, we free an item and reuse it 
without regard to RCU. This can potentially mess up the anon_vma locking 
state while we access it.

Is SLOB used at all or have we been lucky so far?

--
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: build error: sparsemem + SLOB

[Randy Dunlap]

Christoph Lameter wrote:
> On Sun, 19 Nov 2006, Randy Dunlap wrote:
> 
>> mm/sparse.c: line 35 uses slab_is_available() but SLAB=n, SLOB=y.
> 
> I wonder if its worth bothering about SLOB?

It's OK with me to make some combination of SLOB and SPARSEMEM
an invalid config, as long as that is implemented in Kconfig.

> As far as I can tell SLOB is fundamentally racy since it does not support 
> SLAB_DESTROY_BY_RCU correctly. F.e. The constructor for the anon_vma will 
> be called on alloc without regard for RCU, we free an item and reuse it 
> without regard to RCU. This can potentially mess up the anon_vma locking 
> state while we access it.
> 
> Is SLOB used at all or have we been lucky so far?


-- 
~Randy

--
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: build error: sparsemem + SLOB

[Hugh Dickins]

On Mon, 20 Nov 2006, Christoph Lameter wrote:
> 
> As far as I can tell SLOB is fundamentally racy since it does not support 
> SLAB_DESTROY_BY_RCU correctly. F.e. The constructor for the anon_vma will 
> be called on alloc without regard for RCU, we free an item and reuse it 
> without regard to RCU. This can potentially mess up the anon_vma locking 
> state while we access it.

Good find!

> Is SLOB used at all or have we been lucky so far?

Lucky so far.  Well, we'd actually have to be quite unlucky to ever
see what page_lock_anon_vma/SLAB_DESTROY_BY_RCU are guarding against.

But you're absolutely right that users should not be exposed to such
unsafety.  I'd say SLOB should be disallowed if SMP.

Hugh

--
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: build error: sparsemem + SLOB

[Matt Mackall]

On Mon, Nov 20, 2006 at 05:28:24PM +0000, Hugh Dickins wrote:
> On Mon, 20 Nov 2006, Christoph Lameter wrote:
> > 
> > As far as I can tell SLOB is fundamentally racy since it does not support 
> > SLAB_DESTROY_BY_RCU correctly. F.e. The constructor for the anon_vma will 
> > be called on alloc without regard for RCU, we free an item and reuse it 
> > without regard to RCU. This can potentially mess up the anon_vma locking 
> > state while we access it.
> 
> Good find!
> 
> > Is SLOB used at all or have we been lucky so far?
>
> Lucky so far.  Well, we'd actually have to be quite unlucky to ever
> see what page_lock_anon_vma/SLAB_DESTROY_BY_RCU are guarding against.
>
> But you're absolutely right that users should not be exposed to such
> unsafety.  I'd say SLOB should be disallowed if SMP.

SLOB is an O(N) allocator and is pretty poorly suited to running on
anything like a modern desktop. Disallowing if SMP is probably
reasonable, as even machines with multicore ARM or MIPS will probably
have enough memory to make SLOB a bit painful.

-- 
Mathematics is the supreme nostalgia of our time.

--
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: build error: sparsemem + SLOB

[Christoph Lameter]

On Mon, 20 Nov 2006, Hugh Dickins wrote:

> Lucky so far.  Well, we'd actually have to be quite unlucky to ever
> see what page_lock_anon_vma/SLAB_DESTROY_BY_RCU are guarding against.

Hmmm... I had to repeatedly fix my new slab code when I broke 
DESTROY_BY_RCU. The machine wont even boot if that is not done right.

--
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: build error: sparsemem + SLOB

[Yasunori Goto]

> On Mon, Nov 20, 2006 at 05:28:24PM +0000, Hugh Dickins wrote:
> > On Mon, 20 Nov 2006, Christoph Lameter wrote:
> > > 
> > > As far as I can tell SLOB is fundamentally racy since it does not support 
> > > SLAB_DESTROY_BY_RCU correctly. F.e. The constructor for the anon_vma will 
> > > be called on alloc without regard for RCU, we free an item and reuse it 
> > > without regard to RCU. This can potentially mess up the anon_vma locking 
> > > state while we access it.
> > 
> > Good find!
> > 
> > > Is SLOB used at all or have we been lucky so far?
> >
> > Lucky so far.  Well, we'd actually have to be quite unlucky to ever
> > see what page_lock_anon_vma/SLAB_DESTROY_BY_RCU are guarding against.
> >
> > But you're absolutely right that users should not be exposed to such
> > unsafety.  I'd say SLOB should be disallowed if SMP.
> 
> SLOB is an O(N) allocator and is pretty poorly suited to running on
> anything like a modern desktop. Disallowing if SMP is probably
> reasonable, as even machines with multicore ARM or MIPS will probably
> have enough memory to make SLOB a bit painful.

Ok. It's simple. This is fix.

----

This is to disallow to make SLOB with SMP or SPARSEMEM.
This avoids latent troubles of SLOB with SLAB_DESTROY_BY_RCU.
And fix compile error.

This patch is for 2.6.19-rc5-mm2.


Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>

----
 init/Kconfig |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: 19-rc5-mm2/init/Kconfig
===================================================================
--- 19-rc5-mm2.orig/init/Kconfig	2006-11-21 13:41:31.000000000 +0900
+++ 19-rc5-mm2/init/Kconfig	2006-11-21 14:21:31.000000000 +0900
@@ -465,7 +465,7 @@ config SHMEM
 
 config SLAB
 	default y
-	bool "Use full SLAB allocator" if EMBEDDED
+	bool "Use full SLAB allocator" if (EMBEDDED && !SMP && !SPARSEMEM)
 	help
 	  Disabling this replaces the advanced SLAB allocator and
 	  kmalloc support with the drastically simpler SLOB allocator.


-- 
Yasunori Goto 


--
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: build error: sparsemem + SLOB

[Randy Dunlap]

On Tue, 21 Nov 2006 14:57:23 +0900 Yasunori Goto wrote:

> > On Mon, Nov 20, 2006 at 05:28:24PM +0000, Hugh Dickins wrote:
> > > On Mon, 20 Nov 2006, Christoph Lameter wrote:
> > > > 
> > > > As far as I can tell SLOB is fundamentally racy since it does not support 
> > > > SLAB_DESTROY_BY_RCU correctly. F.e. The constructor for the anon_vma will 
> > > > be called on alloc without regard for RCU, we free an item and reuse it 
> > > > without regard to RCU. This can potentially mess up the anon_vma locking 
> > > > state while we access it.
> > > 
> > > Good find!
> > > 
> > > > Is SLOB used at all or have we been lucky so far?
> > >
> > > Lucky so far.  Well, we'd actually have to be quite unlucky to ever
> > > see what page_lock_anon_vma/SLAB_DESTROY_BY_RCU are guarding against.
> > >
> > > But you're absolutely right that users should not be exposed to such
> > > unsafety.  I'd say SLOB should be disallowed if SMP.
> > 
> > SLOB is an O(N) allocator and is pretty poorly suited to running on
> > anything like a modern desktop. Disallowing if SMP is probably
> > reasonable, as even machines with multicore ARM or MIPS will probably
> > have enough memory to make SLOB a bit painful.
> 
> Ok. It's simple. This is fix.
> 
> ----
> 
> This is to disallow to make SLOB with SMP or SPARSEMEM.
> This avoids latent troubles of SLOB with SLAB_DESTROY_BY_RCU.
> And fix compile error.
> 
> This patch is for 2.6.19-rc5-mm2.
> 
> 
> Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>

Acked-by: Randy Dunlap <randy.dunlap@oracle.com>

Thanks.

> ----
>  init/Kconfig |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> Index: 19-rc5-mm2/init/Kconfig
> ===================================================================
> --- 19-rc5-mm2.orig/init/Kconfig	2006-11-21 13:41:31.000000000 +0900
> +++ 19-rc5-mm2/init/Kconfig	2006-11-21 14:21:31.000000000 +0900
> @@ -465,7 +465,7 @@ config SHMEM
>  
>  config SLAB
>  	default y
> -	bool "Use full SLAB allocator" if EMBEDDED
> +	bool "Use full SLAB allocator" if (EMBEDDED && !SMP && !SPARSEMEM)
>  	help
>  	  Disabling this replaces the advanced SLAB allocator and
>  	  kmalloc support with the drastically simpler SLOB allocator.
> 
> 
> -- 

---
~Randy

--
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: build error: sparsemem + SLOB

[Hugh Dickins]

On Mon, 20 Nov 2006, Christoph Lameter wrote:
> On Mon, 20 Nov 2006, Hugh Dickins wrote:
> 
> > Lucky so far.  Well, we'd actually have to be quite unlucky to ever
> > see what page_lock_anon_vma/SLAB_DESTROY_BY_RCU are guarding against.
> 
> Hmmm... I had to repeatedly fix my new slab code when I broke 
> DESTROY_BY_RCU. The machine wont even boot if that is not done right.

I'm intrigued, and a little worried: won't even boot!  Do you have some
particular SGI monster in mind when you say "The machine"?  Why was such a
narrow (preemption disabled) window in page_lock_anon_vma so vulnerable?
Swamped with many or slow-to-handle interrupts?  Or was your slab code
grossly over-eager in trying to free pages?

Hugh

--
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: build error: sparsemem + SLOB

[Hugh Dickins]

On Tue, 21 Nov 2006, Yasunori Goto wrote:
> 
> Ok. It's simple. This is fix.

Acked-by: Hugh Dickins <hugh@veritas.com>

Thanks, and to Christoph and Matt.

--
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: build error: sparsemem + SLOB

[Matt Mackall]

On Tue, Nov 21, 2006 at 02:57:23PM +0900, Yasunori Goto wrote:
> > On Mon, Nov 20, 2006 at 05:28:24PM +0000, Hugh Dickins wrote:
> > > On Mon, 20 Nov 2006, Christoph Lameter wrote:
> > > > 
> > > > As far as I can tell SLOB is fundamentally racy since it does not support 
> > > > SLAB_DESTROY_BY_RCU correctly. F.e. The constructor for the anon_vma will 
> > > > be called on alloc without regard for RCU, we free an item and reuse it 
> > > > without regard to RCU. This can potentially mess up the anon_vma locking 
> > > > state while we access it.
> > > 
> > > Good find!
> > > 
> > > > Is SLOB used at all or have we been lucky so far?
> > >
> > > Lucky so far.  Well, we'd actually have to be quite unlucky to ever
> > > see what page_lock_anon_vma/SLAB_DESTROY_BY_RCU are guarding against.
> > >
> > > But you're absolutely right that users should not be exposed to such
> > > unsafety.  I'd say SLOB should be disallowed if SMP.
> > 
> > SLOB is an O(N) allocator and is pretty poorly suited to running on
> > anything like a modern desktop. Disallowing if SMP is probably
> > reasonable, as even machines with multicore ARM or MIPS will probably
> > have enough memory to make SLOB a bit painful.
> 
> Ok. It's simple. This is fix.

Are there any implications for preemptible kernels here?

-- 
Mathematics is the supreme nostalgia of our time.

--
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: build error: sparsemem + SLOB

[Matt Mackall]

On Tue, Nov 21, 2006 at 11:32:57AM -0800, Christoph Lameter wrote:
> On Tue, 21 Nov 2006, Matt Mackall wrote:
> 
> > Are there any implications for preemptible kernels here?
> 
> Matt: Would  you mind if I replace SLOB with my new slab design? It is as 
> memory efficient as yours (maybe even more since we do not have the 
> header for each allocation). It can work efficiently in an SMP system 
> (NUMA still under test). The code is more complex though. 
> Still needs to mature.

How's the code size compare? 

-- 
Mathematics is the supreme nostalgia of our time.

--
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: build error: sparsemem + SLOB

[Christoph Lameter]

On Tue, 21 Nov 2006, Matt Mackall wrote:

> Are there any implications for preemptible kernels here?

Matt: Would  you mind if I replace SLOB with my new slab design? It is as 
memory efficient as yours (maybe even more since we do not have the 
header for each allocation). It can work efficiently in an SMP system 
(NUMA still under test). The code is more complex though. 
Still needs to mature.


--
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: build error: sparsemem + SLOB

[Hugh Dickins]

On Tue, 21 Nov 2006, Matt Mackall wrote:
> 
> Are there any implications for preemptible kernels here?

I believe not: because that code which relies upon SLAB_DESTROY_BY_RCU's
guarantee already has to use rcu_read_lock(), which disables preemption.

Hugh

--
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>