lkml.org 
[lkml]   [2022]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 07/11] mm: memcontrol: make all the callers of {folio,page}_memcg() safe
    On Mon, May 30, 2022 at 03:49:15PM +0800, Muchun Song wrote:
    > When we use objcg APIs to charge the LRU pages, the page will not hold
    > a reference to the memcg associated with the page. So the caller of the
    > {folio,page}_memcg() should hold an rcu read lock or obtain a reference
    > to the memcg associated with the page to protect memcg from being
    > released. So introduce get_mem_cgroup_from_{page,folio}() to obtain a
    > reference to the memory cgroup associated with the page.
    >
    > In this patch, make all the callers hold an rcu read lock or obtain a
    > reference to the memcg to protect memcg from being released when the LRU
    > pages reparented.
    >
    > We do not need to adjust the callers of {folio,page}_memcg() during
    > the whole process of mem_cgroup_move_task(). Because the cgroup migration
    > and memory cgroup offlining are serialized by @cgroup_mutex. In this
    > routine, the LRU pages cannot be reparented to its parent memory cgroup.
    > So {folio,page}_memcg() is stable and cannot be released.
    >
    > This is a preparation for reparenting the LRU pages.
    >
    > Signed-off-by: Muchun Song <songmuchun@bytedance.com>

    Acked-by: Roman Gushchin <roman.gushchin@linux.dev>

    The locking seems to be correct. I'm slightly worried about a potential
    perf degradation, especially on dying cgroups, where css_get() is relatively
    expensive. I hope getting it into mm-unstable will help to determine
    whether it's actually a problem.

    Thanks!

    \
     
     \ /
      Last update: 2022-06-19 21:38    [W:3.178 / U:0.648 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site