On Fri, 22 Feb 2013, Glauber Costa wrote: > Although not verified in practice, I also point out that it is not safe to scan > the full list only when debugging is on in this case. As unlikely as it is, it > is theoretically possible for the pages to be full. If they are, they will > become unreachable. Aside from scanning the full list, we also need to make > sure that the pages indeed sit in there: the easiest way to do it is to make > sure the boot caches have the SLAB_STORE_USER debug flag set. SLAB_STORE_USER typically increases the size of the managed object. It is not available when slab debugging is not compiled in. There is no list of full slab objects that is maintained in the non debug case and if the allocator is compiled without debug support also the code to manage full lists will not be present. Only one or two kmem_cache item is allocated in the bootstrap code and so far the size of the objects was signficantly smaller than page size. So the slab pages will be on the partial lists. Why are your slab management structures so large that a page can no longer contain multiple objects? If you have that issue then I would suggest to find another way to track the early object (you could f.e. determine the page addresses from the object and go through the slab pages like that). -- 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>