From: Waiman Long <longman@redhat.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Shuah Khan <shuah@kernel.org>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH-cgroup 1/2] cgroup/cpuset: Account for boot time isolated CPUs
Date: Tue, 27 Aug 2024 20:07:01 -0400 [thread overview]
Message-ID: <db9c50d1-4a44-47aa-91ab-0ae33be6ef2a@redhat.com> (raw)
In-Reply-To: <7ropw3hu6low47tklrjj66zb4ldrzzes7rkn5vwfguu5jvvr3a@3lxrzrbqbod7>
On 8/27/24 04:01, Michal Koutný wrote:
> Hi.
>
> On Tue, Aug 20, 2024 at 03:55:35PM GMT, Waiman Long <longman@redhat.com> wrote:
>> The prstate_housekeeping_conflict() function does check the
>> HK_TYPE_DOMAIN housekeeping cpumask to make sure that CPUs outside of it
>> can only be used in isolated partition.
>> Given the fact that we are going to make housekeeping cpumasks
>> dynamic, the current check may not be right anymore. Save the boot
>> time HK_TYPE_DOMAIN cpumask and check against it instead of the
>> upcoming dynamic HK_TYPE_DOMAIN housekeeping cpumask.
> Why is (will be) checking against the stored HK_TYPE_DOMAIN mask correct
> when this mask becomes dynamic?
In term of isolated CPUs, there are 2 categories - static and dynamic.
Statically isolated CPUs are those that are designed as isolated at boot
time by "isolcpus". Other isolated CPUs created by the cpuset isolated
partitions are considered dynamic in the sense that its state can change
at run time. The degree of CPU isolation of dynamically isolated CPUs
isn't as good as that of the statically isolated ones. So I want to
handle them separately which is what the prstate_housekeeping_conflict()
is intended to do.
As it is my intention to make the housekeeping cpumasks dynamic, I need
to keep a copy of the statically isolated CPUs and check against them.
There is no point to check dynamically isolated CPUs as the test may
produce a false positive result.
In the future when dynamic CPU isolation is as almost as good as the
static ones, we can get rid of this distinction and treat all of them as
dynamic.
Cheers,
Longman
next prev parent reply other threads:[~2024-08-28 0:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-20 19:55 [PATCH-cgroup 0/2] cgroup/cpuset: Account for boot time isolated CPUs Waiman Long
2024-08-20 19:55 ` [PATCH-cgroup 1/2] " Waiman Long
2024-08-27 8:01 ` Michal Koutný
2024-08-28 0:07 ` Waiman Long [this message]
2024-08-20 19:55 ` [PATCH-cgroup 2/2] selftest/cgroup: Make test_cpuset_prs.sh deal with pre-isolated CPUs Waiman Long
2024-08-26 19:01 ` [PATCH-cgroup 0/2] cgroup/cpuset: Account for boot time isolated CPUs Waiman Long
2024-08-26 19:05 ` Tejun Heo
2024-08-26 19:41 ` Waiman Long
2024-08-26 20:16 ` Tejun Heo
2024-08-30 19:24 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=db9c50d1-4a44-47aa-91ab-0ae33be6ef2a@redhat.com \
--to=longman@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=mkoutny@suse.com \
--cc=shuah@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox