Hello Tejun Heo,
I've backported the schedule_on_each_cpu() "direct excution" patch on
3.0.30-rt50,
and It fixed my problem.
attachment is the effective patch.
However, I do not understand why machine1 can expose problem, but
machine2 not.
I guess, because it's rt-kernel's preempt
Hello Tejun Heo,
I've backported the schedule_on_each_cpu() direct excution patch on
3.0.30-rt50,
and It fixed my problem.
attachment is the effective patch.
However, I do not understand why machine1 can expose problem, but
machine2 not.
I guess, because it's rt-kernel's preempt
On Fri, Jun 07, 2013 at 10:24:50AM +0800, we...@kylinos.com.cn wrote:
> >Before the commit you originally quoted, the calling thread could be
> preempted and migrated to another CPU before get_online_cpus() thus
> ending up executing the function twice on the new cpu but skipping the
> old one.
>
On Fri, Jun 07, 2013 at 10:24:50AM +0800, we...@kylinos.com.cn wrote:
Before the commit you originally quoted, the calling thread could be
preempted and migrated to another CPU before get_online_cpus() thus
ending up executing the function twice on the new cpu but skipping the
old one.
does
In the previous message,You mentioned:
by the way, I'm wondering about what's the race condition before
which doesn't exist now
Before the commit you originally quoted, the calling thread could be
preempted and migrated to another CPU before get_online_cpus() thus
ending up executing
it's preemption mode related ,
on the 3.0.30-rt50, only config kernel with highest preemption level
(Fully Preemptible Kernel (RT)) in cpu preemption model
will cause problem
and even i use the "Preemptible Kernel" or "Preemptible Kernel
(Low-Latency Desktop)" the problem would not
Hello,
On Thu, Jun 06, 2013 at 06:14:46PM +0800, 韦奇 wrote:
> Hello, Tejun Heo
> thanks for your help,
> 1) I've test the two kernel version on this problem:
> latest
> 3.10-rc3：(https://www.kernel.org/pub/linux/kernel/v3.x/testing/linux-3.10-rc3.tar.xz)
> latest 3.0branch -
>
Hello,
On Thu, Jun 06, 2013 at 06:14:46PM +0800, 韦奇 wrote:
Hello, Tejun Heo
thanks for your help,
1) I've test the two kernel version on this problem:
latest
3.10-rc3：(https://www.kernel.org/pub/linux/kernel/v3.x/testing/linux-3.10-rc3.tar.xz)
latest 3.0branch -
it's preemption mode related ,
on the 3.0.30-rt50, only config kernel with highest preemption level
(Fully Preemptible Kernel (RT)) in cpu preemption model
will cause problem
and even i use the Preemptible Kernel or Preemptible Kernel
(Low-Latency Desktop) the problem would not happen..
In the previous message,You mentioned:
by the way, I'm wondering about what's the race condition before
which doesn't exist now
Before the commit you originally quoted, the calling thread could be
preempted and migrated to another CPU before get_online_cpus() thus
ending up executing
On Fri, May 31, 2013 at 12:07:15PM +0800, we...@kylinos.com.cn wrote:
>
> >the only way for them to get stuck is if there aren't enough execution
> >resources (ie. if a new thread can't be created) but OOM killers would
> >have been activated if that were the case.
>
> The following is a
On Fri, May 31, 2013 at 12:07:15PM +0800, we...@kylinos.com.cn wrote:
the only way for them to get stuck is if there aren't enough execution
resources (ie. if a new thread can't be created) but OOM killers would
have been activated if that were the case.
The following is a detailed
12 matches
Mail list logo
