2014년 08월 13일 18:18에 Chris Redpath 이(가) 쓴 글:
On 13/08/14 05:28, Munyoung Hwang wrote:
Hello Chris,
After appling below patch, I met software deadlock while hmp_idle_pull.
commit 940407d585a1a632086159d19e71bc190a1d07f9 Author: Chris Redpath <chris.redpath@arm.com mailto:chris.redpath@arm.com> Date: Fri May 9 14:36:53 2014 +0100
hmp: Use idle pull to perform forced up-migrationsThe problem is occurred when current task is ksoftirqd and hmp_idle_pull decide to pull a task.
Call stack is as below.
current: ksoftirqd/4
kthread+0xc0 smp_boot_thread_fn+0x118 schedule+0x40 need_resched+0x768 idle_balance+0x180 hmp_idle_pull+0x348 hrtimer_start+0x30 __hrtimer_start_range_ns+0x3a4 raise_softirq_irqoff+0x34 wakeup_softirqd+0x38 wake_up_process+0x34 try_to_wake_up+0x68
I use lsk 14.06 based kernel.
It spins below line on try_to_wake_up. #ifdef CONFIG_SMP /* * If the owning (remote) cpu is still in the middle of schedule() with * this task as prev, wait until its done referencing the task. */ while (p->on_cpu) cpu_relax(); <----------- spinning
Are you aware of this issue? If so, do you have a patch for this?
Thanks, Munyoung.
Hi Munyoung,
This is not something I have seen happen on our platforms, but I would have expected to see it at some point given the report. I wonder if something in our tc2 kernel config prevents this being called at the right time.. would you be able to mail me your config so I can take a look?
In the mean time, can you proceed with your work without using this patch? The benefit is usually pretty small in most cases. I will try to knock up a quick patch to allow this to be turned on and off at runtime and then it could be easily turned off without causing merge issues for later patches while we sort out any issues like this.
Best Regards, Chris
Thanks for reply. I will try without the patch.
By the way, I have question about the patch. the patch uses hrtimer_start for keeping alive current core.
static void hmp_cpu_keepalive_trigger(void) { int cpu = smp_processor_id(); ....
if (ktime_to_ns(keepalive->delay)) hrtimer_start(&keepalive->timer, keepalive->delay, HRTIMER_MODE_REL_PINNED); }
this calls __hrtimer_start_range_ns with wakeup parameter as 1.
int hrtimer_start(struct hrtimer *timer, ktime_t tim, const enum hrtimer_mode mode) { return __hrtimer_start_range_ns(timer, tim, 0, mode, 1); }
wakeup parameter set as 1 means that hrtimer can wake ksoftirqd task up. Is this intended by your patch? even if current is ksoftirqd?
Thanks, Munyoung.