Re: [PATCH v3 4/7] memcg: remove memcg from the reclaim iterators

From: Glauber Costa
Date: Wed Feb 13 2013 - 03:11:49 EST

On 02/12/2013 09:37 PM, Johannes Weiner wrote:
>> > All reads from root->dead_count are atomic already, so I am not sure
>> > what you mean here. Anyway, I hope I won't make this even more confusing
>> > if I post what I have right now:
> Yes, but we are doing two reads. Can't the memcg that we'll store in
> last_visited be offlined during this and be freed after we drop the
> rcu read lock? If we had just one read, we would detect this
> properly.

I don't want to add any more confusion to an already fun discussion, but
IIUC, you are trying to avoid triggering a second round of reclaim in an
already dead memcg, right?

Can't you generalize the mechanism I use for kmemcg, where a very
similar problem exists ? This is how it looks like:

/* this atomically sets a bit in the memcg. It does so
* unconditionally, and it is (so far) okay if it is set
* twice

* Then if kmem charges is not zero, we don't actually destroy the
* memcg. The function where it lives will always be called when usage
* reaches 0, so we guarantee that we will never miss the chance to
* call the destruction function at least once.
* I suspect you could use a mechanism like this, or extend
* this very same, to prevent the second reclaim to be even called
if (res_counter_read_u64(&memcg->kmem, RES_USAGE) != 0)

* this is how we guarantee that the destruction fuction is called at
* most once. The second caller would see the bit unset.
if (memcg_kmem_test_and_clear_dead(memcg))

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at