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
*/
memcg_kmem_mark_dead(memcg);
/*
* 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)
return;
/*
* 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))
mem_cgroup_put(memcg);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
