From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B63163AB288 for ; Tue, 23 Jun 2026 05:58:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782194330; cv=none; b=WtlR0rucZik+5V0ICPAepIQMhnQWpbPXqQQb8OynV+6c4XpGOiIpS2uj0krfl4f37pUZYw7v116dhzPCrspBRTwq6vBTv3W1Oqdfj8GwIRvmwgee0WhHl2rU7wmfr6Kt+9D4tmXhtuFdS1GWCThhJfT0m6e6D1BY/j6p72wuYMo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782194330; c=relaxed/simple; bh=AlU4gtFEKhlfSxIcTjRL4e5qmxfg+fDinLPn8byO1XM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L+XnYGp0EzIPCYPan6RRFXlj3fEG2GmyTeiBy1M+llqZa9znGzfRq2mUeKHWfvRgMEJTJfkAbh6f0TSnhf/yEBB1NvDSkYBl5khCQDw0IPFT/mn95DFWPU6VZaoQ93JAIKFMipVECsq5vUjSIOdBK5vmbD/zuBIX+eOqA2XH/e8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=YnI6bB9E; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YnI6bB9E" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782194327; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IRi8GfAYniLHbjGZFFwKyffd57VQQpHVn1aSTa2bqtc=; b=YnI6bB9ENrTaqC9Rbo1G8sr5mqjdi+1Wd/UQKak5anwc2u2mrSUT9MiEPWOLrCJVJF/fwV M4WdwoLzKNo9gvR5t91QlQHCjk2IRjqDve6d9UP3HmYYhfp/cKq3hmxVD66RCMxMBOaBvR OJ+eQIVQ5RgTck2ZL3+GzKGokmKcLXs= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-272-loA_pPl1MIKCMNAT0kst6g-1; Tue, 23 Jun 2026 01:58:44 -0400 X-MC-Unique: loA_pPl1MIKCMNAT0kst6g-1 X-Mimecast-MFC-AGG-ID: loA_pPl1MIKCMNAT0kst6g_1782194322 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F3E29180064A; Tue, 23 Jun 2026 05:58:41 +0000 (UTC) Received: from [10.2.16.35] (unknown [10.2.16.35]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A040D1956041; Tue, 23 Jun 2026 05:58:39 +0000 (UTC) Message-ID: <74bd7410-7c57-41dc-911e-99969282893e@redhat.com> Date: Tue, 23 Jun 2026 01:58:38 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] cgroup/cpuset: Avoid unnecessary cpus & mems update in cpuset_hotplug_update_tasks() To: Ridong Chen , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Jonathan Corbet , Shuah Khan Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org References: <20260622224509.1927419-1-longman@redhat.com> Content-Language: en-US From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 On 6/22/26 9:14 PM, Ridong Chen wrote: > > > On 6/23/2026 6:45 AM, Waiman Long wrote: >> As reported by sashiko [1], cpuset_hotplug_update_tasks() may perform >> unnecessary task iteration and updating of tasks' CPU and node masks >> when mems_allowed and/or cpus_allowed are not set in cpuset v2. It is >> due to the fact that the temporary new_cpus and new_mems masks do not >> inherit parent's effective_cpus/mems when they are empty which is the >> expected behavior for cpuset v2 since commit 4ec22e9c5a90 ("cpuset: >> Enable cpuset controller in default hierarchy"). >> >> Fix that and avoid unnecessay work by adding the empty mask checks and >> inheriting the parent's versions if empty. >> >> [1] >> https://sashiko.dev/#/patchset/20260621032816.1806773-1-longman%40redhat.com >> >> Fixes: 4ec22e9c5a90 ("cpuset: Enable cpuset controller in default >> hierarchy") >> Signed-off-by: Waiman Long >> --- >>   kernel/cgroup/cpuset.c | 8 ++++++++ >>   1 file changed, 8 insertions(+) >> >> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >> index aff86acea701..bc0207fd6e57 100644 >> --- a/kernel/cgroup/cpuset.c >> +++ b/kernel/cgroup/cpuset.c >> @@ -3925,6 +3925,14 @@ static void cpuset_hotplug_update_tasks(struct >> cpuset *cs, struct tmpmasks *tmp) >>       compute_effective_cpumask(&new_cpus, cs, parent); >>       nodes_and(new_mems, cs->mems_allowed, parent->effective_mems); >>   +    if (is_in_v2_mode()) { >> +        /* Inherit parent's effective_cpus/mems if empty */ >> +        if (cpumask_empty(&new_cpus)) >> +            cpumask_copy(&new_cpus, parent->effective_cpus); >> +        if (nodes_empty(new_mems)) >> +            new_mems = parent->effective_mems; >> +    } >> + >>       if (!tmp || !cs->partition_root_state) >>           goto update_tasks; > > I noticed that compute_effective_cpumask(...) is called in several > places, so I think the logic should be consolidated into that function. > > ``` > static void compute_effective_cpumask(struct cpumask *new_cpus, >                       struct cpuset *cs, struct cpuset *parent) > { >     cpumask_and(new_cpus, cs->cpus_allowed, parent->effective_cpus); >     if (cpumask_empty(&new_cpus) && is_in_v2_mode()) >         cpumask_copy(&new_cpus, parent->effective_cpus); > } > > ``` > > Similarly, for new_mems, should we introduce a dedicated helper like > compute_effective_nodemask? The same fallback logic is needed in > update_nodemasks_hier: > > > ``` > static void update_nodemasks_hier(struct cpuset *cs, nodemask_t > *new_mems) > { > ... >         bool has_mems = nodes_and(*new_mems, cp->mems_allowed, > parent->effective_mems); > >         /* >          * If it becomes empty, inherit the effective mask of the >          * parent, which is guaranteed to have some MEMs. >          */ >         if (is_in_v2_mode() && !has_mems) >             *new_mems = parent->effective_mems; > ... > ``` > Yes, that makes sense. Will adopt this approach in the next version. Cheers, Longman