Home » Mailing lists » Devel » [PATCH v3 00/16] slab accounting for memcg
| Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches [message #47971 is a reply to message #47913] |
Fri, 21 September 2012 09:31   |
Glauber Costa
Messages: 916
Registered: October 2011
|
Senior Member |
|
|
On 09/21/2012 01:28 PM, JoonSoo Kim wrote:
> Hi, Glauber.
>
>>> 2012/9/18 Glauber Costa <glommer@parallels.com>:
>>>> diff --git a/mm/slub.c b/mm/slub.c
>>>> index 0b68d15..9d79216 100644
>>>> --- a/mm/slub.c
>>>> +++ b/mm/slub.c
>>>> @@ -2602,6 +2602,7 @@ redo:
>>>> } else
>>>> __slab_free(s, page, x, addr);
>>>>
>>>> + kmem_cache_verify_dead(s);
>>>> }
>>>
>>> As far as u know, I am not a expert and don't know anything about memcg.
>>> IMHO, this implementation may hurt system performance in some case.
>>>
>>> In case of memcg is destoried, remained kmem_cache is marked "dead".
>>> After it is marked,
>>> every free operation to this "dead" kmem_cache call
>>> kmem_cache_verify_dead() and finally call kmem_cache_shrink().
>>
>> As long as it is restricted to that cache, this is a non issue.
>> dead caches are exactly what they name imply: dead.
>>
>> Means that we actively want them to go away, and just don't kill them
>> right away because they have some inflight objects - which we expect not
>> to be too much.
>
> Hmm.. I don't think so.
> We can destroy memcg whenever we want, is it right?
wrong.
it is impossible to track objects to a task, so when tasks are moved,
objects stay. Which means that some objects are still referenced by the
cache.
> If it is right, there is many inflight objects when we destory memcg.
> If there is so many inflight objects, performance of these processes
> can be hurt too much.
>
There are in-flight objects. It is not expected to have "many inflight
objects", which is a different statement.
We are assuming all the time that the workloads that goes into a cgroup
are mostly nature. When it goes away, most of the objects that were
referenced are expected to go away. Because we can't guarantee all of
them will, the references stay.
When we are able to call shrink_slab() directly on a memcg slab, which
is WIP, we'll be able make those objects even rarer.
>>> And, I found one case that destroying memcg's kmem_cache don't works properly.
>>> If we destroy memcg after all object is freed, current implementation
>>> doesn't destroy kmem_cache.
>>> kmem_cache_destroy_work_func() check "cachep->memcg_params.nr_pages == 0",
>>> but in this case, it return false, because kmem_cache may have
>>> cpu_slab, and cpu_partials_slabs.
>>> As we already free all objects, kmem_cache_verify_dead() is not invoked forever.
>>> I think that we need another kmem_cache_shrink() in
>>> kmem_cache_destroy_work_func().
>>
>> I'll take a look here. What you describe makes sense, and can
>> potentially happen. I tried to handle this case with care in
>> destroy_all_caches, but I may have always made a mistake...
>>
>> Did you see this actively happening, or are you just assuming this can
>> happen from your read of the code?
>
> Just read of the code.
>
I will go through it again, just in case. This is indeed subtle and it
is in my best interest to sort out those issues early.
|
|
|
|
 |
|
[PATCH v3 00/16] slab accounting for memcg
|
|
|
[PATCH v3 02/16] slub: use free_page instead of put_page for freeing kmalloc allocation
|
|
|
[PATCH v3 01/16] slab/slub: struct memcg_params
|
|
|
[PATCH v3 03/16] slab: Ignore the cflgs bit in cache creation
|
|
|
Re: [PATCH v3 03/16] slab: Ignore the cflgs bit in cache creation
|
|
|
Re: [PATCH v3 03/16] slab: Ignore the cflgs bit in cache creation
By: Tejun Heo on Fri, 21 September 2012 17:33 |
|
|
[PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
By: Tejun Heo on Fri, 21 September 2012 20:07 |
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
|
|
|
Re: [PATCH v3 09/16] sl[au]b: always get the cache from its page in kfree
By: Tejun Heo on Fri, 21 September 2012 20:16 |
|
|
[PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
|
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
By: Tejun Heo on Fri, 21 September 2012 18:32 |
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
|
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
By: Tejun Heo on Mon, 24 September 2012 17:56 |
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
|
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
|
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
By: Tejun Heo on Fri, 21 September 2012 20:52 |
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
|
|
|
Re: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache
By: Tejun Heo on Mon, 24 September 2012 17:58 |
|
|
[PATCH v3 04/16] provide a common place for initcall processing in kmem_cache
|
|
|
Re: [PATCH v3 04/16] provide a common place for initcall processing in kmem_cache
|
|
|
[PATCH v3 07/16] memcg: skip memcg kmem allocations in specified code regions
|
|
|
Re: [PATCH v3 07/16] memcg: skip memcg kmem allocations in specified code regions
By: Tejun Heo on Fri, 21 September 2012 19:59 |
|
|
Re: [PATCH v3 07/16] memcg: skip memcg kmem allocations in specified code regions
|
|
|
Re: [PATCH v3 07/16] memcg: skip memcg kmem allocations in specified code regions
By: Tejun Heo on Mon, 24 September 2012 17:47 |
|
|
[PATCH v3 12/16] memcg/sl[au]b Track all the memcg children of a kmem_cache.
|
|
|
Re: [PATCH v3 12/16] memcg/sl[au]b Track all the memcg children of a kmem_cache.
By: Tejun Heo on Fri, 21 September 2012 20:31 |
|
|
[PATCH v3 14/16] slub: slub-specific propagation changes.
|
|
|
[PATCH v3 16/16] Add documentation about the kmem controller
|
|
|
[PATCH v3 08/16] slab: allow enable_cpu_cache to use preset values for its tunables
|
|
|
Re: [PATCH v3 08/16] slab: allow enable_cpu_cache to use preset values for its tunables
|
|
|
Re: [PATCH v3 08/16] slab: allow enable_cpu_cache to use preset values for its tunables
|
|
|
Re: [PATCH v3 08/16] slab: allow enable_cpu_cache to use preset values for its tunables
|
|
|
[PATCH v3 10/16] sl[au]b: Allocate objects from memcg cache
|
|
|
[PATCH v3 13/16] slab: slab-specific propagation changes.
|
|
|
Re: [PATCH v3 13/16] slab: slab-specific propagation changes.
|
|
|
Re: [PATCH v3 13/16] slab: slab-specific propagation changes.
|
|
|
[PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
By: Tejun Heo on Fri, 21 September 2012 18:14 |
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
By: christoph on Mon, 24 September 2012 12:41 |
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
|
|
|
[PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
By: Tejun Heo on Fri, 21 September 2012 20:40 |
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
By: Tejun Heo on Mon, 24 September 2012 17:43 |
|
|
Re: [PATCH v3 15/16] memcg/sl[au]b: shrink dead caches
|
|
|
[PATCH v3 11/16] memcg: destroy memcg caches
|
|
|
Re: [PATCH v3 11/16] memcg: destroy memcg caches
By: Tejun Heo on Fri, 21 September 2012 20:22 |
|
|
Re: [PATCH v3 00/16] slab accounting for memcg
|
|
|
Re: [PATCH v3 00/16] slab accounting for memcg
|
|
|
Re: [PATCH v3 00/16] slab accounting for memcg
By: Tejun Heo on Fri, 21 September 2012 20:46 |
|
|
Re: [PATCH v3 00/16] slab accounting for memcg
By: Tejun Heo on Fri, 21 September 2012 20:47 |
|
|
Re: [PATCH v3 00/16] slab accounting for memcg
|
Goto Forum:
Current Time: Sat Jul 12 12:52:38 GMT 2025
Total time taken to generate the page: 0.02538 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
