On Thu, Nov 28, 2024 at 09:05:34AM GMT, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > It's enforced by the -complex- state machine used to tear down > control groups. True. > tl;dr: If the memcg gets torn down, it will reparent the objects on > the LRU to it's parent memcg during the teardown process. > > This reparenting happens in the cgroup ->css_offline() method, which > only happens after the cgroup reference count goes to zero and is > waited on via: What's waited for is seeing "killing" of the _initial_ reference, the refcount may be still non-zero. I.e. ->css_offline() happens with some referencs around (e.g. from struct page^W folio) and only ->css_released() is called after refs drop to zero (and ->css_free() even after RCU period given there were any RCU readers who didn't css_get()). > See the comment above css_free_rwork_fn() for more details about the > teardown process: > > /* > * css destruction is four-stage process. > * > * 1. Destruction starts. Killing of the percpu_ref is initiated. > * Implemented in kill_css(). > * > * 2. When the percpu_ref is confirmed to be visible as killed on all CPUs > * and thus css_tryget_online() is guaranteed to fail, the css can be > * offlined by invoking offline_css(). After offlining, the base ref is > * put. Implemented in css_killed_work_fn(). > * > * 3. When the percpu_ref reaches zero, the only possible remaining > * accessors are inside RCU read sections. css_release() schedules the > * RCU callback. > * > * 4. After the grace period, the css can be freed. Implemented in > * css_free_rwork_fn(). This is a useful comment. HTH, Michal
Attachment:
signature.asc
Description: PGP signature
