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.
Cc: stable@vger.kernel.org # 4.19.x 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
On Mon, Jan 06, 2025 at 05:24:21PM +0800, wujing wrote:
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:
Again, 4.19.y is long end-of-life.
Also, always do your development work on the latest kernel version, this is documented well in the source tree, right?
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org