On Wed 05-06-13 15:27:09, Tejun Heo wrote:
> On Wed, Jun 05, 2013 at 03:20:21PM -0700, Tejun Heo wrote:
> > Yo,
> >
> > On Wed, Jun 05, 2013 at 05:17:04PM -0400, Johannes Weiner wrote:
> > > That could be an advantage, yes. But keep in mind that every
> > > destruction has to perform this invalidation operation against the
> > > global root_mem_cgroup's nr_node * nr_zone * nr_priority_levels
> > > iterators, so you can't muck around forever, while possibly holding a
> > > lock at this level. It's not a hot path, but you don't want to turn
> > > it into one, either.
> >
> > nr_node tends to be pretty low in most cases, so it shouldn't be a
> > problem there but yeah with high enough nodes and high enough rate of
>
> Also, do we need to hold a lock? It doesn't have to be completely
> strict, so we might as well get away with something like,
>
> for_each_cached_pos() {
> if (hint == me) {
> /* simple clearing implementation, we prolly wanna push it forward */
> cached = xchg(hint, NULL);
> if (cached)
> css_put(cached);
> }
> }
This would be racy:
mem_cgroup_iter
rcu_read_lock
__mem_cgroup_iter_next cgroup_destroy_locked
css_tryget(memcg)
atomic_add(CSS_DEACT_BIAS)
offline_css(memcg)
xchg(memcg, NULL)
mem_cgroup_iter_update
iter->last_visited = memcg
rcy_read_unlock
But if it was called from call_rcu the we should be safe AFAICS.
> It still scans the memory but wouldn't create any contention.
>
> Thanks.
>
> --
> tejun
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>