On Thu, Aug 07, 2014 at 10:03:09PM +0900, Joonsoo Kim wrote: > 2014-08-07 21:53 GMT+09:00 Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>: > > Hi, > > > > On Thu, Aug 7, 2014 at 2:36 PM, Joonsoo Kim <js1304@xxxxxxxxx> wrote: > >>> With latest mainline, I'm getting a crash during bootup on m68k/ARAnyM: > >>> > >>> enable_cpucache failed for radix_tree_node, error 12. > >>> kernel BUG at /scratch/geert/linux/linux-m68k/mm/slab.c:1522! > > > >>> I bisected it to commit a640616822b2c3a8009b0600f20c4a76ea8a0025 > >>> Author: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > >>> Date: Wed Aug 6 16:04:38 2014 -0700 > >>> > >>> slab: remove BAD_ALIEN_MAGIC > > > >> This patch only works for !NUMA. And if num_possible_nodes() is 1, > >> then it doesn't have any effect, because alloc_alien_cache() call is always > >> skipped. Is it possible !NUMA and num_possible_nodes() != 1? > >> > >> Could you check your config for CONFIG_NUMA and > >> CONFIG_NODES_SHIFT? > > > > $ grep CONFIG_NUMA .config > > $ grep CONFIG_NODES_SHIFT .config > > CONFIG_NODES_SHIFT=3 > > $ > > > > There are indeed multiple nodes: > > > > On node 0 totalpages: 3584 > > free_area_init_node: node 0, pgdat 003659a4, node_mem_map 00402000 > > DMA zone: 32 pages used for memmap > > DMA zone: 0 pages reserved > > DMA zone: 3584 pages, LIFO batch:0 > > On node 1 totalpages: 65536 > > free_area_init_node: node 1, pgdat 00366294, node_mem_map 00426090 > > DMA zone: 576 pages used for memmap > > DMA zone: 0 pages reserved > > DMA zone: 65536 pages, LIFO batch:15 > > > >> And, could you check booting with boot param "noaliencache"? > > > > That fixes the boot, too. > > Ah... I don't know it can be possible to be !CONFIG_NUMA and > CONFIG_NODES_SHIFT > 0 until now. If so, I should revert this patch. > > After some more investigation, I will revert this patch tomorrow and > notify you. > > Thanks for reporting!!! :) Hello, Just for curiosity. Could you show me your full dmesg on boot-up? What I want to know is nodes-cpus mapping. I looked at SLAB code and found that SLAB works fine only if numa_mem_id() always returns 0. I guess that this is the case for !CONFIG_NUMA, so your system would work fine. And, I looked at SLUB code and found that SLUB works fine only if page_to_nid(page) always return 0 for this !CONFIG_NUMA and many nodes case. If not, some memory could be leak, I guess. If possible, could you check whether page_to_nid(page) returns only 0 or not? Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>