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 93A9A1F4C8C for ; Sat, 27 Dec 2025 07:41:00 +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=1766821262; cv=none; b=g0aWj2W4aEjOCrdMTMwtKn1zpXbog9ELw0qCrKmioSxXD1lJO79v11UfrBg30HmvLyE/5iBZqGMxq1SY5Am3f6TjT9ZdXVdFtPeGeJJ0aNn3tLlht4Iba9V4tUIGUOY7If1jRBV1Zep3TDc2Z7FTKRZSrTDm+PBbGDfouUE9DNk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766821262; c=relaxed/simple; bh=GWtzsTSxe+yrXs4I8eYcoSILdQU19ahQAnlt20TmvIU=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=f8prXN5BoS6/7UHujYzrJG2ZjpDLWymxVN7NvvO6vQZDJBczxp1lrp9ORfjuRFtrjGSKA94ORpRFO+6gA6PISx0ThRsuvMByB53tRVMWzlJQ2JQJHO9rkLjYMmtld7XX+BSvAnGpmoQr/QNfZWzrxPhAN+zbY6zI7nBv4EyFIns= 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=EOA0kVOn; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=MyuhzFc4; 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="EOA0kVOn"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="MyuhzFc4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1766821259; 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=0DwNcOke2gK/ioxlvj0fBOzstfubMNacxjBocotOUEI=; b=EOA0kVOnRVlxiKzWU4GbfmrG+3rPCSIOH062L7opM1vGgzzGfZ7XouFZVQ6zISsLLjvXno OyNOa73sco9dwqfyyy0noua2xoW+1kwg3DiAxAi4MMJYry7yvIm5K0YXPCVOHfjtsFX1px WgrP9Ijj6AyfLLOQLJaS39HrF1KCicw= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-413-TlO7uVKhNciWcrN-JZv9zw-1; Sat, 27 Dec 2025 02:40:57 -0500 X-MC-Unique: TlO7uVKhNciWcrN-JZv9zw-1 X-Mimecast-MFC-AGG-ID: TlO7uVKhNciWcrN-JZv9zw_1766821257 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8b259f0da04so1852309585a.0 for ; Fri, 26 Dec 2025 23:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1766821257; x=1767426057; 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=0DwNcOke2gK/ioxlvj0fBOzstfubMNacxjBocotOUEI=; b=MyuhzFc4fntWToVuQsDdzWApd7/KpZPHzgecCcbsgIgRHK2dVzRccePxQm0NMbvqxB xfT6/UA1Zrnr9UCBs/HSuzfYREnfJvpyRHDIZktucsc4J/g7P32EuWLUXU+607GhLlBb WfW5Fvi0ViLcTEO7hVpQlzoqC3k/2fJc+ivhG6B9XpuwD95XUAVhhFg+n9TfO8a+RdD3 khfBugP7HTQwQJBKDI9M+K3u5V7N102IDU6M1UvQtM7K8ttw9ZaWy41hId4K/xQ3eBe5 Wq2hjuCnbtvW8PUP8ZP09pFr8omxTVnIngzA54vPesbpbh6tzNMLHy4qx1ALyFRZAIRQ i1Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766821257; x=1767426057; 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=0DwNcOke2gK/ioxlvj0fBOzstfubMNacxjBocotOUEI=; b=qMOe9eeWcSo/t4qyV07P+XxCUg7FnoynkXcf7Pu14k6EswuJyM2uQfrOQEKbTTsaXt sOeJwhsVBKB/ixKDLGIJob2+ebaN5uALBqLx2Bkn4HRzlx6tAMHF3Hp21Fbhprsb6o2b +svLkCICz3ajQs/mdytzXnbxzugRt3CZbIodx60Uy09cRlmuBMeMCDzsWTWn2oUHoV57 0wwdPJZOSDyW2Ntw2ZeqhhT1RzOcGw1O0cerZZgeOXLfQvGhI6NRtzt0PqQp9JtLdH/n aNCXj7eHSBbcNAJyc2VUBv8lfP9hgT0Lhmy0HD2ojEFL1phRnKeWSCNR87PXHBihL995 cTAg== X-Gm-Message-State: AOJu0YymHiPC4loY0bEYg/Aovve3nbw8fSfJu0IFxPOv7i3mapr26EF5 QC17zr9RbyhwykOn+cS61lrmj+oAc/VlQrc8CLZOaPWcr7yv4jzePwrxeN1rCQ9Hv1GoOxIyll/ h4qjPzll6EoTZEsRstmREmeJ1S0X4JBtpy4zxOAZ0wpMOPb2n/Aq83jKrwpMay7V3Ww== X-Gm-Gg: AY/fxX4xjsTLLpVKuZZbxHwTWetPhL2HidV48kfd9JUmVnHMGXxItMY2tRfx4d1ZxFs Qj7jkrxs328rtxt9sjjykB5EO4qbpDyHrCxT76YXG5HUf3du3qRTiwPSWpUhsLp6CCz3AtjR+5j CvnWRr5jjCCr5F9iyr/zet+CCTpDlNnAzyMybwAzGka+OdE9Tf5CvSls74UfhOGqUTTpy1RmDXj r+U3lRVOtVM00OtNYWmOk/MpEH9VlNt1+VhZHoxIZZJjGiA0KTtLGuylO5HStIOsp2iAF7LulEQ uXbqq8EShzk7r22lMgrs2ecTnr1NqoEm9otGHuSyqWHcEdpUgpBcuZe+hy70KyplStsUcNiurpI mODGu9MkxkItSmOxZw1YTH0E440phzJ5L/+ZF98vtbKfNVVrNAK4JT94Q X-Received: by 2002:a05:620a:4054:b0:89e:67a9:fced with SMTP id af79cd13be357-8c08fabf2damr3557710585a.66.1766821256971; Fri, 26 Dec 2025 23:40:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IHxd8EoY1n2eid3yg9nQXs4eblN/ICVLhfJ8sEY7sdfxSLJXXU/pJM9ooykELoGhas/1nicTA== X-Received: by 2002:a05:620a:4054:b0:89e:67a9:fced with SMTP id af79cd13be357-8c08fabf2damr3557709085a.66.1766821256489; Fri, 26 Dec 2025 23:40:56 -0800 (PST) Received: from ?IPV6:2601:600:947f:f020:85dc:d2b2:c5ee:e3c4? ([2601:600:947f:f020:85dc:d2b2:c5ee:e3c4]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c0975ee7d5sm1887454885a.49.2025.12.26.23.40.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Dec 2025 23:40:55 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <2988a9d5-fe25-4668-93e3-8335360fcbec@redhat.com> Date: Sat, 27 Dec 2025 02:40:53 -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: [cgroup/for-6.20 PATCH 1/4] cgroup/cpuset: Streamline rm_siblings_excl_cpus() To: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Shuah Khan Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, Sun Shaojie References: <20251225073056.30789-1-longman@redhat.com> <20251225073056.30789-2-longman@redhat.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/25/25 4:27 AM, Chen Ridong wrote: > > On 2025/12/25 15:30, Waiman Long wrote: >> If exclusive_cpus is set, effective_xcpus must be a subset of >> exclusive_cpus. Currently, rm_siblings_excl_cpus() checks both >> exclusive_cpus and effective_xcpus connectively. It is simpler >> to check only exclusive_cpus if non-empty or just effective_xcpus >> otherwise. >> >> No functional change is expected. >> >> Signed-off-by: Waiman Long >> --- >> kernel/cgroup/cpuset.c | 17 +++++++++-------- >> 1 file changed, 9 insertions(+), 8 deletions(-) >> >> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >> index 221da921b4f9..3d2d28f0fd03 100644 >> --- a/kernel/cgroup/cpuset.c >> +++ b/kernel/cgroup/cpuset.c >> @@ -1355,23 +1355,24 @@ static int rm_siblings_excl_cpus(struct cpuset *parent, struct cpuset *cs, >> int retval = 0; >> >> if (cpumask_empty(excpus)) >> - return retval; >> + return 0; >> >> /* >> * Exclude exclusive CPUs from siblings >> */ >> rcu_read_lock(); >> cpuset_for_each_child(sibling, css, parent) { >> + struct cpumask *sibling_xcpus; >> + >> if (sibling == cs) >> continue; >> >> - if (cpumask_intersects(excpus, sibling->exclusive_cpus)) { >> - cpumask_andnot(excpus, excpus, sibling->exclusive_cpus); >> - retval++; >> - continue; >> - } >> - if (cpumask_intersects(excpus, sibling->effective_xcpus)) { >> - cpumask_andnot(excpus, excpus, sibling->effective_xcpus); >> + sibling_xcpus = cpumask_empty(sibling->exclusive_cpus) >> + ? sibling->effective_xcpus >> + : sibling->exclusive_cpus; >> + > I'm wondering if this is sufficient? > > sibling_xcpus = sibling->effective_xcpus > > p(exclusive_cpus = 1) > / \ > a b(root, exclusive_cpus=1-7, effective_xcpus=1) > > What the sibling's effective exclusive CPUs actually should be is not CPUs 1-7 but CPU 1. So, do we > need to remove CPUs 2-7? By definition, exclusive_cpus have to be exclusive within the same child cpuset level even if some of the CPUs cannot be granted from the parent. So other siblings cannot use any of the CPUs 1-7 in its exclusive_cpus list or the writing will fail. In the case of cpuset.cpus defined partitions, those CPUs will be removed from its effective_xcpus list. Cheers, Longman