On 09/10/2015 03:47 AM, Christoph Lameter wrote: > On Wed, 9 Sep 2015, Paul E. McKenney wrote: > >> > But then again kfree() contains a barrier() which would block the compiler >> > from moving anything into the free path. >> >> That barrier() is implicit in the fact that kfree() is an external >> function? Or are my eyes failing me? Is the "external function" not enough? Does it change e.g. with LTO, or is that also subject to the aliasing rules (which I admit not knowing exactly)? > > kfree at some point calls slab_free(). That function has a barrier. All > free operations go through it. SLAB doesn't have such barrier AFAICS. It will put the object on per-cpu cache and that's it. Only flushing the full cache takes a spin lock. > > -- > 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> > -- 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>