On Tue, 26 Apr 2016, Andrew Morton wrote: > : CONFIG_FREELIST_RANDOM bugs me a bit - "freelist" is so vague. > : CONFIG_SLAB_FREELIST_RANDOM would be better. I mean, what Kconfig > : identifier could be used for implementing randomisation in > : slub/slob/etc once CONFIG_FREELIST_RANDOM is used up? > > but this pearl appeared to pass unnoticed. Ok. lets add SLAB here and then use this option for the other allocators as well. > > + /* If it fails, we will just use the global lists */ > > + cachep->random_seq = kcalloc(count, sizeof(freelist_idx_t), GFP_KERNEL); > > + if (!cachep->random_seq) > > + return -ENOMEM; > > OK, no BUG. If this happens, kmem_cache_init_late() will go BUG > instead ;) > > Questions for slab maintainers: > > What's going on with the gfp_flags in there? kmem_cache_init_late() > passes GFP_NOWAIT into enable_cpucache(). > > a) why the heck does it do that? It's __init code! enable_cpucache() was called when a slab cache was reconfigured by writing to /proc/slabinfo. That was changed awhile back when the memcg changes were made ot slab. So now its ok to be made init code. > Finally, all callers of enable_cpucache() (and hence of > cache_random_seq_create()) are __init, so we're unnecessarily bloating > up vmlinux. Could someone please take a look at this as a separate > thing? Hmmm. Well if that is the case then lots of stuff could be straightened out. Joonsoo? -- 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>