[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140205162701.GB2786@htj.dyndns.org>
Date: Wed, 5 Feb 2014 11:30:32 -0500
From: Tejun Heo <tj@...nel.org>
To: Michal Hocko <mhocko@...e.cz>
Cc: Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [PATCH -v2 4/6] memcg: make sure that memcg is not offline when
charging
Hello, Michal.
On Wed, Feb 05, 2014 at 05:19:40PM +0100, Michal Hocko wrote:
> > Well, css_free() is the callback invoked when the ref counter hits 0,
> > and that is a guarantee. From a memcg perspective, it's the right
> > place to do reparenting, not css_offline().
>
> OK, it seems I've totally misunderstood what is the purpose of
> css_offline. My understanding was that any attempt to css_tryget will
Heh, the semantics have changed significantly during the past year.
It started as something pretty unusual (synchronous ref draining on
rmdir) and took some iterations to reach the current design and we
still don't have any proper documentation, so misunderstanding
probably is inevitable, sorry. :)
> fail when css_offline starts. I will read through Tejun's email as well
> and think about it some more.
Yes, css_tryget() is guaranteed to fail once css_offline() starts.
This is to help ref draining so that controllers have a scalable way
to reliably decide when to say no to new usages. Please note that
css_get() is still allowed even after css_offline() (of course as long
as the caller already has a ref).
Thanks!
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists