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.129.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 54F673090FE for ; Wed, 26 Nov 2025 03:26:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764127580; cv=none; b=ojPEUF9avPxk88Vx5eSqc+mCFYs0NcWbdEyA3xvPjpeNg8JuAIQzDELajbUVKDHL8SSP1yGd9f1xkktGoSKHBqi/SVNBA1cLUUodr9zwg9S9IbGmQOe/R3wLaW+ig4HZNCiAph3gMQs/0BNYBdXaIyUgyHdGpmg1NxT/Wd9wJEE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764127580; c=relaxed/simple; bh=Sia2yxR8V7Pcxur4TtpiiyVbyxm4JnMGYfaNB44J6BM=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=S+N33xf03JV9QZcPe25P4Usdz4ARpitmXsPB4MjrWlrqr8zDqe86hZmf3U4cbOSqWBSj6htcwCuI3DeXq5aTe+O4DREisdQe//67RQR5TqbykoKV4DWPUmrsc6rY015Uci8ICZSLdUaG7WHP6p7lylvEw6JoNT/AFmbEMr/3TDQ= 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=aG5K32rs; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=OYhycvr0; arc=none smtp.client-ip=170.10.129.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="aG5K32rs"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="OYhycvr0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1764127577; 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=abOUtLUsvu/QAaSWZZCQTqM++QBrk8MYEct289JwQg4=; b=aG5K32rsKxtRO/REuOLTkmlL57qDB1bJP/BV/GK/zYp+Klpm9uWXPBDoht2NihbqTxrLtv 3tuR/MDTNjiOxIjcPDlHV5HVMdt43m7FSy7ncHaHj5TPHUjlDgomKb5ArcMi0ZzQA/1JHh TLtyBbPQgUzZ1NfAILT9KbvQFMfO+I4= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-133-vtLD5t0aO1CadRbIb7GRUw-1; Tue, 25 Nov 2025 22:26:15 -0500 X-MC-Unique: vtLD5t0aO1CadRbIb7GRUw-1 X-Mimecast-MFC-AGG-ID: vtLD5t0aO1CadRbIb7GRUw_1764127574 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8b259f0da04so1622372885a.0 for ; Tue, 25 Nov 2025 19:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1764127574; x=1764732374; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=abOUtLUsvu/QAaSWZZCQTqM++QBrk8MYEct289JwQg4=; b=OYhycvr0QJvvfjgbd8U0Ff5hrocxh2QVHAdptzd232+111yCQY6JDJ3gKRSrVqR9w3 dA9oR5sK4a7piG1Di7IudgD2J9HtUjtK4lf0OouOePOotbw5YTGlF0eY4HaUjSwQQcYa Xvx2L9ISfje5U27VkfuJQw63w3bNnQGrnkZTahxOAZf7Mx5Yd+jIGanVuFGxjU/OtnTi bUjg330PlwO0WGNqixxF10UWDp9WyA4YurzmbR171F6Wm9tWP9DZrgBAgxTxcMZ2Aro8 vu79kPJAxG9KVNSajQT6CWLTHF5cWhNn/noj11SqkEGLenm/J1CWyXYdMKH9br2KOO8K 8YXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764127574; x=1764732374; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=abOUtLUsvu/QAaSWZZCQTqM++QBrk8MYEct289JwQg4=; b=w9ZbAAWlRysBkQWHfytzxXDSHFicO3x5bxp37JbzJoltGpeTkFVTFOxnGtMbkOpRva zHT3nJi8UQLIUY60Za74Fi3ru8uqEpIy6MaC5dtOAZ1PEWMC8y90hKFQMCa3si5ZFyN9 iBuEn+4Bem5uRGAPnvluHRDynBVoilTXioNTkysViAXWtxfiO6pHuuLpETmNpPQuv1iB +3S7N4QvKQuyFleH3mqjJZN4bak7PpHkBmGWRDc8y2UVHYCQkzwt9fTmmyuPjzNIvX6q flnOTyhPrk3VlJJ+oEA7UpiF3W/kCWew76NOg8llIw0rIH0+E01Dda+w0srTLBAhpgDQ Q+GA== X-Forwarded-Encrypted: i=1; AJvYcCWoryxJJ5mSvGekUC3jM3/ZYtDlCU/BZJlM6XHMA6MHYHfdQK5iZvFvuP5oMVyHNWIWdiL79q1WKWqX9V4=@vger.kernel.org X-Gm-Message-State: AOJu0YwmzM94TVNDnhIdKX1QyYQBlseCT0HaJcEB8X2lFWvsGEb5xPHq RYGFjfHlajB3bjb/6FuAiwJ/JYvQj+DbBJVCFbPwMi2a1TWeekLOrwCMg4hyTtgwEmt5ui4d8l2 TSirqsC+vhV4EonubGd5eFumUFWv2W7Z+em4fMfzvWdtIJvfRuBnF/g8IlgsQyBu0mQ== X-Gm-Gg: ASbGnct8mT7IzrCM4RTZU08RWB6KlZSZn3VfTRgpAumkv5j6okKLtEGWoxC+SP9IJ+K EMGQarObaTvCg+w7uN1PAAsKK3n/Loi+X2DQ1ip5Bfm2RIn20ZHz+Ik05cxHAVOJq+jVc7mgyoM 90ao6G9EZSB6I7DhSDMvfK6+ri0Grf4N81xz9G0YsEkVLyeACcYxciTvnyNNDSu3/YGy3BbAq53 ABijuCz7Z1Aa+Z7b3Nm/iZ6Fq+glQ+9ZIFdVX8BywGcfowzOm3joh4lExJzyl9nc3R8WpqEXzGP T5yMzk5KQVly39u4Di4YesTt07dXBML9lC55I77AVjx+RnPN8pKLTKSIHUIEyY0d8OdJLwdAhhU +QOhfbbuuP1wS6Po41NYWe4IM9OfnkgjOXsX4JdD41gTDjqw6yFSW9XBD X-Received: by 2002:a05:620a:2a11:b0:8a2:3be9:1d79 with SMTP id af79cd13be357-8b33d1b2498mr2234141585a.18.1764127574624; Tue, 25 Nov 2025 19:26:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IHUNpA4EZ5VqOhYfNsuWwom+wcXDH1ip4AgAeuaVadWiPDkq4fX/5ASRn/mpAYKFtXMvccJiQ== X-Received: by 2002:a05:620a:2a11:b0:8a2:3be9:1d79 with SMTP id af79cd13be357-8b33d1b2498mr2234138485a.18.1764127574009; Tue, 25 Nov 2025 19:26:14 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b329431460sm1287663185a.15.2025.11.25.19.26.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Nov 2025 19:26:13 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Tue, 25 Nov 2025 22:26:12 -0500 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 -next] cpuset: Remove unnecessary checks in rebuild_sched_domains_locked To: Chen Ridong , Waiman Long , tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, daniel.m.jordan@oracle.com, lujialin4@huawei.com, chenridong@huawei.com References: <20251118083643.1363020-1-chenridong@huaweicloud.com> <27ed2c0b-7b00-4be0-a134-3c370cf85d8e@redhat.com> <0ecb1476-2886-430f-a698-cabbe9302129@huaweicloud.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/25/25 10:17 PM, Chen Ridong wrote: > > On 2025/11/26 10:33, Waiman Long wrote: >> On 11/25/25 8:01 PM, Chen Ridong wrote: >>> On 2025/11/26 2:16, Waiman Long wrote: >>>>> active CPUs, preventing partition_sched_domains from being invoked with >>>>> offline CPUs. >>>>> >>>>> Signed-off-by: Chen Ridong >>>>> --- >>>>>    kernel/cgroup/cpuset.c | 29 ++++++----------------------- >>>>>    1 file changed, 6 insertions(+), 23 deletions(-) >>>>> >>>>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >>>>> index daf813386260..1ac58e3f26b4 100644 >>>>> --- a/kernel/cgroup/cpuset.c >>>>> +++ b/kernel/cgroup/cpuset.c >>>>> @@ -1084,11 +1084,10 @@ void dl_rebuild_rd_accounting(void) >>>>>     */ >>>>>    void rebuild_sched_domains_locked(void) >>>>>    { >>>>> -    struct cgroup_subsys_state *pos_css; >>>>>        struct sched_domain_attr *attr; >>>>>        cpumask_var_t *doms; >>>>> -    struct cpuset *cs; >>>>>        int ndoms; >>>>> +    int i; >>>>>          lockdep_assert_cpus_held(); >>>>>        lockdep_assert_held(&cpuset_mutex); >>>> In fact, the following code and the comments above in rebuild_sched_domains_locked() are also no >>>> longer relevant. So you may remove them as well. >>>> >>>>          if (!top_cpuset.nr_subparts_cpus && >>>>              !cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask)) >>>>                  return; >>>> >>> Thank you for reminding me. >>> >>> I initially retained this code because I believed it was still required for cgroup v1, as I recalled >>> that synchronous operation is exclusive to cgroup v2. >>> >>> However, upon re-examining the code, I confirm it can be safely removed. For cgroup v1, >>> rebuild_sched_domains_locked is called synchronously, and only the migration task (handled by >>> cpuset_migrate_tasks_workfn) operates asynchronously. Consequently, cpuset_hotplug_workfn is >>> guaranteed to complete before the hotplug workflow finishes. >> Yes, v1 still have a task migration part that is done asynchronously because of the lock ordering >> issue. Even if this code has to be left because of v1, you should still update the comment to >> reflect that. Please try to keep the comment updated to help others to have a better understanding >> of what the code is doing. >> >> Thanks, >> Longman >> > Hi Longman, > > Just to confirm (in case I misunderstood): I believe it is safe to remove the check on > top_cpuset.effective_cpus (for both cgroup v1 and v2). I will proceed to remove both the > corresponding code and its associated comment(not update the comment). > > if (!top_cpuset.nr_subparts_cpus && > !cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask)) > return; > > Additionally, I should add a comment to clarify the rationale for introducing the > WARN_ON_ONCE(!cpumask_subset(doms[i], cpu_active_mask)) warning. > > Does this approach look good to you? Please let me know if I’ve missed anything or if further > adjustments are needed. > Yes, that is good for me. I was just talking about a hypothetical situation, not that you have to update the comment. Cheers, Longman