Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <25f6a188-4cc6-dace-1468-fd5645711515@shopee.com>
Date:   Thu, 3 Nov 2022 10:13:22 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.4.0
Subject: Re: [PATCH] cgroup: Simplify code in css_set_move_task
To:     =?UTF-8?Q?Michal_Koutn=c3=bd?= <mkoutny@suse.com>
Cc:     tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org,
        cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20221020074701.84326-1-haifeng.xu@shopee.com>
 <20221027080558.GA23269@blackbody.suse.cz>
 <adb7418c-39a2-6202-970a-a039ad8201dd@shopee.com>
 <20221031131140.GC27841@blackbody.suse.cz>
From:   Haifeng Xu <haifeng.xu@shopee.com>
In-Reply-To: <20221031131140.GC27841@blackbody.suse.cz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk


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