This bug can be reproduced on Kunpeng arm64 and Phytium arm physical machines, as well as in virtual machine environments, based on the linux-4.19.y stable branch: 1. Check the number of CPUs on the system: nproc --all 96

2. Add the parameter isolcpus=0-85 to the grub configuration, update grub, and reboot.

3. Check the ksmd process:

ps aux | grep -i ksmd root 502 0.0 0.0 0 0 ? S 10:00 0:00 [ksmd]

ps -o pid,psr,comm -p 502 PID PSR COMMAND 502 0 ksmd

4. Check the kthreadd process:

ps aux | grep -i kthreadd root 2 0.0 0.0 0 0 ? S 10:00 0:00 [kthreadd]

ps -o pid,psr,comm -p 2 PID PSR COMMAND 2 0 kthreadd

From the output above, it can be seen that both ksmd and kthreadd are still running on CPU0, which is unreasonable since CPU0 has been isolated.

Signed-off-by: wujing realwujing@qq.com Signed-off-by: QiLiang Yuan yuanql9@chinatelecom.cn --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 0950cabfc1d0..454021ff70a1 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6211,7 +6211,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t

this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc)); if (!this_sd) - return -1; + return housekeeping_any_cpu(HK_FLAG_DOMAIN);

/* * Due to large variance we need a large fuzz factor; hackbench in