Re: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
On 07/25/2012 09:13 PM, Christoph Lameter wrote: > On Wed, 25 Jul 2012, Glauber Costa wrote: > >> In the slub allocator, when the last object of a page goes away, we >> don't necessarily free it - there is not necessarily a test for empty >> page in any slab_free path. > > That is true for the slab allocator as well. In either case calling > kmem_cache_shrink() will make the objects go away by draining the cached > objects and freeing the pages used for the objects back to the page > allocator. You do not need this patch. Just call the proper functions to > drop the objecgts in the caches in either allocator. > >> The slab allocator has a time based reaper that would eventually get rid >> of the objects, but we can also call it explicitly, since dead caches >> are not a likely event. > > So this is already for both allocators? > Yes, I just didn't updated the whole changelog. my bad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
On Wed, 25 Jul 2012, Glauber Costa wrote: > In the slub allocator, when the last object of a page goes away, we > don't necessarily free it - there is not necessarily a test for empty > page in any slab_free path. That is true for the slab allocator as well. In either case calling kmem_cache_shrink() will make the objects go away by draining the cached objects and freeing the pages used for the objects back to the page allocator. You do not need this patch. Just call the proper functions to drop the objecgts in the caches in either allocator. > The slab allocator has a time based reaper that would eventually get rid > of the objects, but we can also call it explicitly, since dead caches > are not a likely event. So this is already for both allocators? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
On Wed, 25 Jul 2012, Glauber Costa wrote: In the slub allocator, when the last object of a page goes away, we don't necessarily free it - there is not necessarily a test for empty page in any slab_free path. That is true for the slab allocator as well. In either case calling kmem_cache_shrink() will make the objects go away by draining the cached objects and freeing the pages used for the objects back to the page allocator. You do not need this patch. Just call the proper functions to drop the objecgts in the caches in either allocator. The slab allocator has a time based reaper that would eventually get rid of the objects, but we can also call it explicitly, since dead caches are not a likely event. So this is already for both allocators? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
On 07/25/2012 09:13 PM, Christoph Lameter wrote: On Wed, 25 Jul 2012, Glauber Costa wrote: In the slub allocator, when the last object of a page goes away, we don't necessarily free it - there is not necessarily a test for empty page in any slab_free path. That is true for the slab allocator as well. In either case calling kmem_cache_shrink() will make the objects go away by draining the cached objects and freeing the pages used for the objects back to the page allocator. You do not need this patch. Just call the proper functions to drop the objecgts in the caches in either allocator. The slab allocator has a time based reaper that would eventually get rid of the objects, but we can also call it explicitly, since dead caches are not a likely event. So this is already for both allocators? Yes, I just didn't updated the whole changelog. my bad. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
