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 C4A9331A54E for ; Sun, 4 Jan 2026 21:48:11 +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=1767563293; cv=none; b=UZzkfAvtC6ljxU0NH1RbsRhfCIx4xtGN7qUzkTGLXorotHOCh63V5Q83yDBCjqaLnMbYxSEI7l4TsBhCpifKS2E2ssvhIEDPLiA3v8XdTGicAUIFn13y8YhfGYsnTxonC3CcjrNbv8DHlOYGPSchjHze5rhZf4CuV7tVsR4DT1M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767563293; c=relaxed/simple; bh=y0sc11w6iKkgJZhc5ra4q3irne+xMlYBsG9oiAF3S8E=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=b2WBKQDgCCG2b/Mvjw0NgvtCCIDNG/upfzAuh9nGDa1h6ePOvvxXDn1v1w6dTbelud+WU75LHzpYrXWe4GFdLUg7Y/zmoZWwW1hkosUHLcp+UHyGIhrf+t0PDWLUwAZnugN+JL5gdQNwWo7WMVtBA8QTuOjVIRMzxrFEFbUKg5M= 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=ff1kOcEg; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=tliSzznS; 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="ff1kOcEg"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="tliSzznS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767563290; 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=y078SXfKEIKRd5VwmHPxExsqrlkRflvvVfuy30oz9Iw=; b=ff1kOcEgKxtC/amYFduXAwUExgj9AhYxA7UCwKCns4oeNDxHn/sjxvTnPc3btX3wd7c5Oo va91h52PmunSWXWtxseggIrMAVwGh+0uexD2hleDKgqcp3viw8enmP1ml7juZTdb9m4Jlm W7oQK3tXY2iLqZE+XIVydtiDVOecERQ= 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-31-6jPTKPJXNJOBvmZWiPpr7w-1; Sun, 04 Jan 2026 16:48:09 -0500 X-MC-Unique: 6jPTKPJXNJOBvmZWiPpr7w-1 X-Mimecast-MFC-AGG-ID: 6jPTKPJXNJOBvmZWiPpr7w_1767563289 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8b24383b680so4757939585a.0 for ; Sun, 04 Jan 2026 13:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1767563289; x=1768168089; 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=y078SXfKEIKRd5VwmHPxExsqrlkRflvvVfuy30oz9Iw=; b=tliSzznSG3XM7WGPMZ6z7fcqN5CGzRFZQtKvBTiBSBLM3WJaAJYUYGkteqQzZRR1Wr izKdkqdBAtt28aA3WvNjT+lbeeXNVjJWEDLu4yR/iIKHlZpGbQ2fJNGFzPH4FcC5uPmg tTpHem1CzZ2hZxLRb+IkRmtedLkedDZ73etU7SAu2xwziJgcs2nM7edkGDYrwmVk8ayf nibJqjVC3minQecGRLKxzgovwDGRYFLvK9JuZnD8PGEXoVh7FQQHqvoQKDGUirnSF+VV bPoVqfjoQE5Zkt2HvKPJI2W01pPmn1e0ILFN1jMIoh4xjy4e86FYE+xJCXPaYnC0M8Fv NIVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767563289; x=1768168089; 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=y078SXfKEIKRd5VwmHPxExsqrlkRflvvVfuy30oz9Iw=; b=QcKWMcOzbe+1qrkCejE9wjI6hWB/vteQKAj1q3E2PbI2I5YQzCTURSxPl52e3g5WM5 rnZMvH26/s+g9iQe1hu0oexCzhWFRYczP7rXDwDTZcPibcQ0Q/w+UztrGunBWIusn8lY kQuq4rhXOaeQnlKibI8A7xVWeRQnW1ZQHpAC22PEOGHdJvoT1QoBkrosTdhtHKrAhce8 AnPeLZfStBaDPblHkDxGPChm41AjPgaB8a15MSMNdyMmZJBGJOaOGAyXsoxpK4ETvNpP gAsUZuX0bO8oHetdK6lnAkaH9En3z3flQ6ZUTStQ5Scomeq+mRbmO+II9aG9yEo3Wngl zPFg== X-Gm-Message-State: AOJu0Yzav5x2At1wnDWmO6wWbhuHSatomYO1OnHnTI9vYuJw4aAJ+6wg zDVuaAP4jFAqMERlKYuLz58fHmwkPhVVkayErgZaNUqVeAOInySsMvJgDB5ReVItbqw4sK+aWgP YQ4lysn0fpi4BwhTds/Jcm5JY5eRbaJCWDJcwPZjke/sdGwkRqVZjyU4xbpJmtKMHng== X-Gm-Gg: AY/fxX7z2MnO7op8J5dS6QSz4/LkQMP2qePU9pVPpRZCGWlLJAbEjT4DtFJjtgHx2Fb eDKOgQ400H0KsdFX3UqkjjaCeGq8a59Ta7igYNa1NTLS28MOYijFhNCs66xP0frTA3A8RYqyCQc vGGcfZuFsC0ivkbyMqvK7ICHDjuMykT5vQkOWymd5E/x0ZdVHdvtfyvRYZ1S8CQeob7P98wUX4j vgCIFWaxLyvjnm3WpG4SUS+vs7Ya5p2RsEMugsd/Cf+/wSVAx8Hh07gZ3/qpa0eV905j1y42fDc cPRriDWWiZ0va53zYNxUvu8M/JPhBfPGBID4/zDlKnnxFRfvxxpvQ4djdiKKlj1p+3sR+cgIj0a YglIdUzeUa9QTC6+I62OHSY2O18H3wq4kWgAst14+HWkdvlR00H7JBb5/ X-Received: by 2002:a05:620a:472c:b0:8b2:edf1:7c4a with SMTP id af79cd13be357-8c08f682c7amr7291368685a.39.1767563289032; Sun, 04 Jan 2026 13:48:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IEgx/Ro8LIsSGzA6GrLW/huLR0mhax5aa71Iw9IGeyKEOdpg2Rc4aEZNIq7X9MHlTlbpRgEJg== X-Received: by 2002:a05:620a:472c:b0:8b2:edf1:7c4a with SMTP id af79cd13be357-8c08f682c7amr7291366685a.39.1767563288604; Sun, 04 Jan 2026 13:48:08 -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-8c0973ee08dsm3652997385a.36.2026.01.04.13.48.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Jan 2026 13:48:07 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <6eedf67b-3538-4fd1-903b-b7d8db4ff43d@redhat.com> Date: Sun, 4 Jan 2026 16:48:06 -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 v2 3/4] cgroup/cpuset: Don't fail cpuset.cpus change in v2 To: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Jonathan Corbet , Shuah Khan Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, Sun Shaojie References: <20260101191558.434446-1-longman@redhat.com> <20260101191558.434446-4-longman@redhat.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/4/26 2:09 AM, Chen Ridong wrote: > > On 2026/1/2 3:15, Waiman Long wrote: >> Commit fe8cd2736e75 ("cgroup/cpuset: Delay setting of CS_CPU_EXCLUSIVE >> until valid partition") introduced a new check to disallow the setting >> of a new cpuset.cpus.exclusive value that is a superset of a sibling's >> cpuset.cpus value so that there will at least be one CPU left in the >> sibling in case the cpuset becomes a valid partition root. This new >> check does have the side effect of failing a cpuset.cpus change that >> make it a subset of a sibling's cpuset.cpus.exclusive value. >> >> With v2, users are supposed to be allowed to set whatever value they >> want in cpuset.cpus without failure. To maintain this rule, the check >> is now restricted to only when cpuset.cpus.exclusive is being changed >> not when cpuset.cpus is changed. >> > Hi, Longman, > > You've emphasized that modifying cpuset.cpus should never fail. While I haven't found this > explicitly documented. Should we add it? > > More importantly, does this mean the "never fail" rule has higher priority than the exclusive CPU > constraints? This seems to be the underlying assumption in this patch. Before the introduction of cpuset partition, writing to cpuset.cpus will only fail if the cpu list is invalid like containing CPUs outside of the valid cpu range. What I mean by "never-fail" is that if the cpu list is valid, the write action should not fail. The rule is not explicitly stated in the documentation, but it is a pre-existing behavior which we should try to keep to avoid breaking existing applications. The exclusive CPU constraint does not apply to cpuset.cpus. It only applies when setting cpuset.cpus.exclusive wrt to other cpuset.cpus.exclusive* in sibling cpusets. So I will not say one has higher priority than the other. Cheers, Longman