[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140925100130.GC12090@dhcp22.suse.cz>
Date: Thu, 25 Sep 2014 12:01:30 +0200
From: Michal Hocko <mhocko@...e.cz>
To: Johannes Weiner <hannes@...xchg.org>
Cc: linux-mm@...ck.org, Tejun Heo <tj@...nel.org>,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch v2] mm: memcontrol: convert reclaim iterator to simple
css refcounting
On Wed 24-09-14 13:16:53, Johannes Weiner wrote:
> On Wed, Sep 24, 2014 at 06:47:39PM +0200, Michal Hocko wrote:
> > On Fri 19-09-14 17:28:43, Johannes Weiner wrote:
[...]
> > > - memcg = __mem_cgroup_iter_next(root, last_visited);
> > > + do {
> > > + pos = ACCESS_ONCE(mz->reclaim_iter[priority]);
> > > + } while (pos && !css_tryget(&pos->css));
> >
> > This is a bit confusing. AFAIU css_tryget fails only when the current
> > ref count is zero already. When do we keep cached memcg with zero count
> > behind? We always do css_get after cmpxchg.
> >
> > Hmm, there is a small window between cmpxchg and css_get when we store
> > the current memcg into the reclaim_iter[priority]. If the current memcg
> > is root then we do not take any css reference before cmpxchg and so it
> > might drop down to zero in the mean time so other CPU might see zero I
> > guess. But I do not see how css_get after cmpxchg on such css works.
> > I guess I should go and check the css reference counting again.
>
> It's not about root or the newly stored memcg, it's that you might
> read the position right before it's replaced and css_put(), at which
OK, got it
CPU0 CPU1
pos = reclaim_iter[priority]
cmpxchg(reclaim_iter[priority], pos, memcg)
css_put(pos) # -> 0
css_tryget(pos)
Thanks!
--
Michal Hocko
SUSE Labs
--
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