On Fri, 7 Aug 2015 10:56:09 +0900 Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> wrote: > On Fri, Jul 31, 2015 at 08:57:35AM -0500, Christoph Lameter wrote: > > On Fri, 31 Jul 2015, Joonsoo Kim wrote: > > > > > I don't think that this fix is right. > > > Just "kmalloc_size(INDEX_NODE) * 2" looks insane because it means 192 * 2 > > > = 384 on his platform. Why we need to check size is larger than 384? > > > > Its an arbitrary boundary. Making it large ensures that the smaller caches > > stay operational and do not fall back to page sized allocations. > > If it is an arbitrary boundary, it would be better to use static value > such as "256" rather than kmalloc_size(INDEX_NODE) * 2. > Value of kmalloc_size(INDEX_NODE) * 2 can be different in some archs > and it is difficult to manage such variation. It would cause this kinds of > bug again. I recommand following change. How about it? > > - if (size >= kmalloc_size(INDEX_NODE + 1) > + if (!slab_early_init && > + size >= kmalloc_size(INDEX_NODE) && > + size >= 256 > Guys, can we please finish this off? afaict Jianxuexin's original patch is considered undesirable, but his machine is still going BUG. -- 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>