>>> + * move charges to its parent or the root cgroup if the group has no >>> + * parent (aka use_hierarchy==0). >>> + * Although this might fail (get_page_unless_zero, isolate_lru_page or >>> + * mem_cgroup_move_account fails) the failure is always temporary and >>> + * it signals a race with a page removal/uncharge or migration. In the >>> + * first case the page is on the way out and it will vanish from the LRU >>> + * on the next attempt and the call should be retried later. >>> + * Isolation from the LRU fails only if page has been isolated from >>> + * the LRU since we looked at it and that usually means either global >>> + * reclaim or migration going on. The page will either get back to the >>> + * LRU or vanish. >> >> I just wonder for how long can it go in the worst case? > > That's a good question and to be honest I have no idea. The point is > that it will terminate eventually and that the group is on the way out > so the time to complete the removal is not a big deal IMHO. We had > basically similar situation previously when we would need to repeat > rmdir loop on EBUSY. The only change is that we do not have to retry > anymore. > > So the key point is to check whether my assumption about temporarily is > correct and that we cannot block the rest of the kernel/userspace to > proceed even though we are waiting for finalization. I believe this is > true but... (last famous words?) > At least for me, it seems that this will hold. -- 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>