On 2022/10/31 21:11, Michal Koutný wrote: > Hello. > >> 1) If calls 'css_set_update_populated' , the cset is either getting the >> first task or losing the last. There is a need to update the populated >> state of the cset only when 'css_set_populated' returns false. >> In other words, the last has been deleted from from_cset and the first >> hasn't been added to to_cset yet. > > I've likely misread the condition previously. I see how this works now > (update happens after "from_cset" but before "to_cset" migration). > >> 3) In order to update the populated state of to_cset the same way >> from_cset does, 'css_set_update_populated' is also invoked during the >> process of moving a task to to_cset. > > As I think more about this in the context of vertical migrations > (ancestor<->descendant, such as during controller dis- or enablement), > I'm afraid the inverted order would lead to "spurious" emptiness > notifications in ancestors (in the case a there is just a single task > that migrates parent->child, parent/cgroup.populated would generate and > event that'd be nullified by the subsequent population of the child). Hi, Michal. I understand your worries. Can I just check the populated state of css_set in 'css_set_update_populated' and don't change the order any more? I think it can also streamline 'css_set_move_task' a bit. Thanks, Hiafeng. > > So I'm not sure the change is worth it. > > Michal
