On 08/02/2012 06:28 PM, Christoph Lameter wrote: > On Thu, 2 Aug 2012, Glauber Costa wrote: > >> Which is then the patchset's fault. Since as I said, my call order is: >> >> kmem_cache_create() -> kmem_cache_destroy(). >> >> All allocs and frees are implicit. >> >> It also works okay both before the patches are applied, and with slab. > > Are you creating two identical caches? > In this example, yes. But note that I destroy in the between, so the order is: 1) x = kmem_cache_create(...) 2) kmem_cache_destroy(x); 3) x = kmem_cache_create(...) I am doing this way so I can be sure my slab memcg is not involved. The first time I came across this, was while testing that code. In that environment, the sequence would be: 1) create a cgroup. 2) delete that cgroup 3) create another cgroup. In that scenario, we create a bunch of other caches. All of them differ at least in names, since we append the memcg name to the end of the cache. Also, on the interest of ruling out the "equal caches" hypotheses, I am now creating a second cache that bears no relation whatsoever to the first one I deleted. Problem persists. Although this is not guaranteed, the fact that it works with slab and after this series they look alike a lot more, may point out to aliasing as the cause of this. -- 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>