lkml.org 
[lkml]   [2012]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -V9 14/15] hugetlb/cgroup: migrate hugetlb cgroup info from oldpage to new page during migration
On Wed 13-06-12 15:57:33, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> With HugeTLB pages, hugetlb cgroup is uncharged in compound page destructor. Since
> we are holding a hugepage reference, we can be sure that old page won't
> get uncharged till the last put_page().
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

Reviewed-by: Michal Hocko <mhocko@suse.cz>

One question below
[...]
> +void hugetlb_cgroup_migrate(struct page *oldhpage, struct page *newhpage)
> +{
> + struct hugetlb_cgroup *h_cg;
> +
> + if (hugetlb_cgroup_disabled())
> + return;
> +
> + VM_BUG_ON(!PageHuge(oldhpage));
> + spin_lock(&hugetlb_lock);
> + h_cg = hugetlb_cgroup_from_page(oldhpage);
> + set_hugetlb_cgroup(oldhpage, NULL);
> + cgroup_exclude_rmdir(&h_cg->css);
> +
> + /* move the h_cg details to new cgroup */
> + set_hugetlb_cgroup(newhpage, h_cg);
> + spin_unlock(&hugetlb_lock);
> + cgroup_release_and_wakeup_rmdir(&h_cg->css);
> + return;
> +}
> +

The changelog says that the old page won't get uncharged - which means
that the the cgroup cannot go away (even if we raced with the move
parent, hugetlb_lock makes sure we either see old or new cgroup) so why
do we need to play with css ref. counting?
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic


\
 
 \ /
  Last update: 2012-06-14 12:41    [W:0.290 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site