Re: [PATCH v3 4/6] memcg: replace cgroup_lock with memcg specific memcg_lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon 21-01-13 17:33:49, Michal Hocko wrote:
> On Mon 21-01-13 20:12:17, Glauber Costa wrote:
> > On 01/21/2013 08:07 PM, Michal Hocko wrote:
> > >> > And the reason why kmemcg holds the set_limit mutex
> > >> > is just to protect from itself, then there is no *need* to hold any
> > >> > extra lock (and we'll never be able to stop holding the creation lock,
> > >> > whatever it is). So my main point here is not memcg_mutex vs
> > >> > set_limit_mutex, but rather, memcg_mutex is needed anyway, and once it
> > >> > is taken, the set_limit_mutex *can* be held, but doesn't need to.
> > > So you can update kmem specific usage of set_limit_mutex.
> > Meaning ?
> 
> I thought you've said it is not needed and the code says that:
> - memcg_propagate_kmem is called with memcg_mutex held in css_alloc
> - memcg_update_kmem_limit takes both of them
> - kmem_cache_destroy_memcg_children _doesn't_ take both
> 
> So one obvious way to go would be changing
> kmem_cache_destroy_memcg_children to memcg_mutex and removing
> set_limit_mutex from other two paths.
> 
> This would leave set_limit_mutex lock for its original intention.

And then we could use a more suitable name: memcg_create_lock

-- 
Michal Hocko
SUSE Labs

--
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>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]