* build error: sparsemem + SLOB @ 2006-11-20 5:05 Randy Dunlap 2006-11-20 11:22 ` [PATCH]Re: " Yasunori Goto 2006-11-20 17:03 ` Christoph Lameter 0 siblings, 2 replies; 16+ messages in thread From: Randy Dunlap @ 2006-11-20 5:05 UTC (permalink / raw) To: linux-mm 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH]Re: build error: sparsemem + SLOB 2006-11-20 5:05 build error: sparsemem + SLOB Randy Dunlap @ 2006-11-20 11:22 ` Yasunori Goto 2006-11-20 17:02 ` Randy Dunlap 2006-11-20 17:03 ` Christoph Lameter 1 sibling, 1 reply; 16+ messages in thread From: Yasunori Goto @ 2006-11-20 11:22 UTC (permalink / raw) To: Randy Dunlap; +Cc: linux-mm > 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH]Re: build error: sparsemem + SLOB 2006-11-20 11:22 ` [PATCH]Re: " Yasunori Goto @ 2006-11-20 17:02 ` Randy Dunlap 0 siblings, 0 replies; 16+ messages in thread From: Randy Dunlap @ 2006-11-20 17:02 UTC (permalink / raw) To: Yasunori Goto; +Cc: linux-mm 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-20 5:05 build error: sparsemem + SLOB Randy Dunlap 2006-11-20 11:22 ` [PATCH]Re: " Yasunori Goto @ 2006-11-20 17:03 ` Christoph Lameter 2006-11-20 17:08 ` Randy Dunlap 2006-11-20 17:28 ` Hugh Dickins 1 sibling, 2 replies; 16+ messages in thread From: Christoph Lameter @ 2006-11-20 17:03 UTC (permalink / raw) To: Randy Dunlap; +Cc: linux-mm, mpm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-20 17:03 ` Christoph Lameter @ 2006-11-20 17:08 ` Randy Dunlap 2006-11-20 17:28 ` Hugh Dickins 1 sibling, 0 replies; 16+ messages in thread From: Randy Dunlap @ 2006-11-20 17:08 UTC (permalink / raw) To: Christoph Lameter; +Cc: linux-mm, mpm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-20 17:03 ` Christoph Lameter 2006-11-20 17:08 ` Randy Dunlap @ 2006-11-20 17:28 ` Hugh Dickins 2006-11-20 18:36 ` Matt Mackall 2006-11-20 21:22 ` Christoph Lameter 1 sibling, 2 replies; 16+ messages in thread From: Hugh Dickins @ 2006-11-20 17:28 UTC (permalink / raw) To: Christoph Lameter; +Cc: Randy Dunlap, linux-mm, mpm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-20 17:28 ` Hugh Dickins @ 2006-11-20 18:36 ` Matt Mackall 2006-11-21 5:57 ` Yasunori Goto 2006-11-20 21:22 ` Christoph Lameter 1 sibling, 1 reply; 16+ messages in thread From: Matt Mackall @ 2006-11-20 18:36 UTC (permalink / raw) To: Hugh Dickins; +Cc: Christoph Lameter, Randy Dunlap, linux-mm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-20 18:36 ` Matt Mackall @ 2006-11-21 5:57 ` Yasunori Goto 2006-11-21 6:59 ` Randy Dunlap ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Yasunori Goto @ 2006-11-21 5:57 UTC (permalink / raw) To: Matt Mackall Cc: Hugh Dickins, Christoph Lameter, Randy Dunlap, linux-mm, Pekka Enberg > 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-21 5:57 ` Yasunori Goto @ 2006-11-21 6:59 ` Randy Dunlap 2006-11-21 13:34 ` Hugh Dickins 2006-11-21 19:14 ` Matt Mackall 2 siblings, 0 replies; 16+ messages in thread From: Randy Dunlap @ 2006-11-21 6:59 UTC (permalink / raw) To: Yasunori Goto Cc: Matt Mackall, Hugh Dickins, Christoph Lameter, linux-mm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-21 5:57 ` Yasunori Goto 2006-11-21 6:59 ` Randy Dunlap @ 2006-11-21 13:34 ` Hugh Dickins 2006-11-21 19:14 ` Matt Mackall 2 siblings, 0 replies; 16+ messages in thread From: Hugh Dickins @ 2006-11-21 13:34 UTC (permalink / raw) To: Yasunori Goto Cc: Matt Mackall, Christoph Lameter, Randy Dunlap, linux-mm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-21 5:57 ` Yasunori Goto 2006-11-21 6:59 ` Randy Dunlap 2006-11-21 13:34 ` Hugh Dickins @ 2006-11-21 19:14 ` Matt Mackall 2006-11-21 19:32 ` Christoph Lameter 2006-11-21 19:54 ` Hugh Dickins 2 siblings, 2 replies; 16+ messages in thread From: Matt Mackall @ 2006-11-21 19:14 UTC (permalink / raw) To: Yasunori Goto Cc: Hugh Dickins, Christoph Lameter, Randy Dunlap, linux-mm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-21 19:14 ` Matt Mackall @ 2006-11-21 19:32 ` Christoph Lameter 2006-11-21 19:29 ` Matt Mackall 2006-11-21 19:54 ` Hugh Dickins 1 sibling, 1 reply; 16+ messages in thread From: Christoph Lameter @ 2006-11-21 19:32 UTC (permalink / raw) To: Matt Mackall Cc: Yasunori Goto, Hugh Dickins, Randy Dunlap, linux-mm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-21 19:32 ` Christoph Lameter @ 2006-11-21 19:29 ` Matt Mackall 0 siblings, 0 replies; 16+ messages in thread From: Matt Mackall @ 2006-11-21 19:29 UTC (permalink / raw) To: Christoph Lameter Cc: Yasunori Goto, Hugh Dickins, Randy Dunlap, linux-mm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-21 19:14 ` Matt Mackall 2006-11-21 19:32 ` Christoph Lameter @ 2006-11-21 19:54 ` Hugh Dickins 1 sibling, 0 replies; 16+ messages in thread From: Hugh Dickins @ 2006-11-21 19:54 UTC (permalink / raw) To: Matt Mackall Cc: Yasunori Goto, Christoph Lameter, Randy Dunlap, linux-mm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-20 17:28 ` Hugh Dickins 2006-11-20 18:36 ` Matt Mackall @ 2006-11-20 21:22 ` Christoph Lameter 2006-11-21 13:31 ` Hugh Dickins 1 sibling, 1 reply; 16+ messages in thread From: Christoph Lameter @ 2006-11-20 21:22 UTC (permalink / raw) To: Hugh Dickins; +Cc: Randy Dunlap, linux-mm, mpm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: build error: sparsemem + SLOB 2006-11-20 21:22 ` Christoph Lameter @ 2006-11-21 13:31 ` Hugh Dickins 0 siblings, 0 replies; 16+ messages in thread From: Hugh Dickins @ 2006-11-21 13:31 UTC (permalink / raw) To: Christoph Lameter; +Cc: Randy Dunlap, linux-mm, mpm, Pekka Enberg 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-11-21 19:54 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-11-20 5:05 build error: sparsemem + SLOB Randy Dunlap 2006-11-20 11:22 ` [PATCH]Re: " Yasunori Goto 2006-11-20 17:02 ` Randy Dunlap 2006-11-20 17:03 ` Christoph Lameter 2006-11-20 17:08 ` Randy Dunlap 2006-11-20 17:28 ` Hugh Dickins 2006-11-20 18:36 ` Matt Mackall 2006-11-21 5:57 ` Yasunori Goto 2006-11-21 6:59 ` Randy Dunlap 2006-11-21 13:34 ` Hugh Dickins 2006-11-21 19:14 ` Matt Mackall 2006-11-21 19:32 ` Christoph Lameter 2006-11-21 19:29 ` Matt Mackall 2006-11-21 19:54 ` Hugh Dickins 2006-11-20 21:22 ` Christoph Lameter 2006-11-21 13:31 ` Hugh Dickins
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox