On 11/15/24 10:45 AM, Michal Koutný wrote:
Hello.
I recently liked the idea of considering isolated CPUs a static (boot
time) resource and only use cpusets to place (or remove) sensitive
workload from those selected CPUs depending on current needs. (Yes, this
may not efficiently utilize the isolated CPUs when reserve them based on
maximum needs of a node.)
Thanks for taking a look at this.
Yes, I am moving in this direction too. Boot time statically isolated
CPUs have better isolation than is currently possible if we do it
dynamically at run time, though we are trying to close the gap.
On Wed, Aug 21, 2024 at 10:23:11AM GMT, Waiman Long <longman@xxxxxxxxxx> wrote:
This patch is a step in that direction by making the housekeeping CPU
mask APIs exclude the dynamically isolated CPUs when they are called
at run time. The housekeeping CPU masks will fall back to the bootup
default when all the dynamically isolated CPUs are released.
But when I look at it with the dynamism in mind, I would expect that
some API like housekeeping_setup_type(), i.e. modify the set of isolated
CPUs are requested and leave it up to the isolation implementation to
propagate any changes to respective subsystems. And return an error of
type contains a flag for which dynamism isn't implemented yet or not
possible.
There are currently 9 different hk_type's defined in
include/linux/sched/isolation.h. We are now trying to reduce their
number as some of them cannot be set independently. See [1]. I am
thinking about doing dynamism in the best effort basis. Of course, we
could expose some information about what aspect of dynamic isolation can
be enabled at the moment, if necessary.
Cheers,
Longman
