* sched_yield() call on Linux Kernel 2.6.39 is not behaving correct
@ 2015-01-07 21:30 Yogesh Ahire
2015-01-08 5:26 ` Mike Galbraith
0 siblings, 1 reply; 6+ messages in thread
From: Yogesh Ahire @ 2015-01-07 21:30 UTC (permalink / raw)
To: linux-kernel
Hi All,
I have a system with multiple CPU cores. I have multiple threads
assigned to particular CPU. Among these threads the main thread calls
sched_yield() if it has nothing to do, I am hoping that doing so will
give chance to other threads to run. But the strange behavior of
sched_yield() is , even if there are ready-to-runs tasks on this CPU
waiting for their turn, the task which calls sched_yield() is always
running ( get scheduled) and not giving chance to any other task to
run. It is consuming 100% of CPU. Is sched_yield() is broken on 2.6
Kernel?
Thanks
Thanks
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sched_yield() call on Linux Kernel 2.6.39 is not behaving correct
2015-01-07 21:30 sched_yield() call on Linux Kernel 2.6.39 is not behaving correct Yogesh Ahire
@ 2015-01-08 5:26 ` Mike Galbraith
2015-01-08 15:00 ` Yogesh Ahire
0 siblings, 1 reply; 6+ messages in thread
From: Mike Galbraith @ 2015-01-08 5:26 UTC (permalink / raw)
To: Yogesh Ahire; +Cc: linux-kernel
On Wed, 2015-01-07 at 16:30 -0500, Yogesh Ahire wrote:
> Hi All,
>
> I have a system with multiple CPU cores. I have multiple threads
> assigned to particular CPU. Among these threads the main thread calls
> sched_yield() if it has nothing to do, I am hoping that doing so will
> give chance to other threads to run. But the strange behavior of
> sched_yield() is , even if there are ready-to-runs tasks on this CPU
> waiting for their turn, the task which calls sched_yield() is always
> running ( get scheduled) and not giving chance to any other task to
> run. It is consuming 100% of CPU. Is sched_yield() is broken on 2.6
> Kernel?
Nope, your expectation is likely busted. sched_yield() for a fair class
task is merely a resched check in CFS. IFF there's a runnable task
that's more deserving by the CFS definition thereof, it'll initiate a
context switch, otherwise it's a non-free noop. For realtime class
tasks, behavior is predictable, the scheduler WILL initiate a context
switch IFF there is a runnable task of >= yielding tasks priority on the
same CPU. If you depend on a context switch happening in any other
circumstance, you're gonna be seriously disappointed.
-Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sched_yield() call on Linux Kernel 2.6.39 is not behaving correct
2015-01-08 5:26 ` Mike Galbraith
@ 2015-01-08 15:00 ` Yogesh Ahire
2015-01-09 3:14 ` Mike Galbraith
0 siblings, 1 reply; 6+ messages in thread
From: Yogesh Ahire @ 2015-01-08 15:00 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-kernel
Thank you Mike. But I can see there are tasks with same priority and
are runnable waiting for CPU, following is the output of
/proc/sched_debug where you can see that the task "symphonyapp"
continuously calls sched_yield() but there are other tasks which are
ready to run are not getting CPU and are queued back.
cpu#4, 2660.325 MHz
.nr_running : 133
.load : 135278
.nr_switches : 3032774521
.nr_load_updates : 4859055152
.nr_uninterruptible : 0
.next_balance : 9153.935253
.curr->pid : 2392
.clock : 1373656869.013078
.cpu_load[0] : 135278
.cpu_load[1] : 116170
.cpu_load[2] : 104329
.cpu_load[3] : 97683
.cpu_load[4] : 93432
.yld_count : 503461840
.sched_switch : 0
.sched_count : -917907006
.sched_goidle : 4735
.avg_idle : 672352
.ttwu_count : 1516392423
.ttwu_local : 1516377141
.bkl_count : 0
cfs_rq[4]:
.exec_clock : 1373608176.832115
.MIN_vruntime : 18008522836.670893
.min_vruntime : 18008522848.670893
.max_vruntime : 18008522959.874760
.spread : 123.203867
.spread0 : 17010031797.944969
.nr_spread_over : -676561100
.nr_running : 133
.load : 135278
rt_rq[4]:
.rt_nr_running : 0
.rt_throttled : 0
.rt_time : 0.000000
.rt_runtime : 950.000000
runnable tasks:
task PID tree-key switches prio
exec-runtime sum-exec sum-sleep
----------------------------------------------------------------------------------------------------------
kworker/4:1 224 18008522836.670893 1516377074 120
18008522836.670893 5565718.111520 18008565537.968010
taskmonitor 10602 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 11695 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 19704 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 25757 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 31287 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 1510 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 14921 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 15377 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 15707 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 16032 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 16629 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
taskmonitor 16695 18008522860.665039 0 120
18008522860.665039 0.000000 0.000000
R symphonyapp 2392 1368041892.701540 1516377057 120
1368041892.702799 1368041445.291337 31.536059
ntpd 9806 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 11577 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 15837 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 20093 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
ice_ai_pca 22944 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 24137 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 27732 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 31330 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 2557 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 6175 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 9775 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 13374 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
crond 16975 18008522856.668288 0 120
18008522856.668288 0.000000 0.000000
Thanks
Yogesh
On Thu, Jan 8, 2015 at 12:26 AM, Mike Galbraith
<umgwanakikbuti@gmail.com> wrote:
> On Wed, 2015-01-07 at 16:30 -0500, Yogesh Ahire wrote:
>> Hi All,
>>
>> I have a system with multiple CPU cores. I have multiple threads
>> assigned to particular CPU. Among these threads the main thread calls
>> sched_yield() if it has nothing to do, I am hoping that doing so will
>> give chance to other threads to run. But the strange behavior of
>> sched_yield() is , even if there are ready-to-runs tasks on this CPU
>> waiting for their turn, the task which calls sched_yield() is always
>> running ( get scheduled) and not giving chance to any other task to
>> run. It is consuming 100% of CPU. Is sched_yield() is broken on 2.6
>> Kernel?
>
> Nope, your expectation is likely busted. sched_yield() for a fair class
> task is merely a resched check in CFS. IFF there's a runnable task
> that's more deserving by the CFS definition thereof, it'll initiate a
> context switch, otherwise it's a non-free noop. For realtime class
> tasks, behavior is predictable, the scheduler WILL initiate a context
> switch IFF there is a runnable task of >= yielding tasks priority on the
> same CPU. If you depend on a context switch happening in any other
> circumstance, you're gonna be seriously disappointed.
>
> -Mike
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sched_yield() call on Linux Kernel 2.6.39 is not behaving correct
2015-01-08 15:00 ` Yogesh Ahire
@ 2015-01-09 3:14 ` Mike Galbraith
2015-01-09 19:24 ` Yogesh Ahire
0 siblings, 1 reply; 6+ messages in thread
From: Mike Galbraith @ 2015-01-09 3:14 UTC (permalink / raw)
To: Yogesh Ahire; +Cc: linux-kernel
On Thu, 2015-01-08 at 10:00 -0500, Yogesh Ahire wrote:
> Thank you Mike. But I can see there are tasks with same priority and
> are runnable waiting for CPU, following is the output of
> /proc/sched_debug where you can see that the task "symphonyapp"
> continuously calls sched_yield() but there are other tasks which are
> ready to run are not getting CPU and are queued back.
Something terminally bad happened. With that tasks vruntime (tree-key),
it's gonna try to yield for one hell of a long time before it succeeds.
-Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sched_yield() call on Linux Kernel 2.6.39 is not behaving correct
2015-01-09 3:14 ` Mike Galbraith
@ 2015-01-09 19:24 ` Yogesh Ahire
2015-01-10 7:37 ` Mike Galbraith
0 siblings, 1 reply; 6+ messages in thread
From: Yogesh Ahire @ 2015-01-09 19:24 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-kernel
Thank you Mike. I didn't get what you mean by saying "its gona try to
yield for one hell of a long time before it succeeds".
On Thu, Jan 8, 2015 at 7:14 PM, Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> On Thu, 2015-01-08 at 10:00 -0500, Yogesh Ahire wrote:
>> Thank you Mike. But I can see there are tasks with same priority and
>> are runnable waiting for CPU, following is the output of
>> /proc/sched_debug where you can see that the task "symphonyapp"
>> continuously calls sched_yield() but there are other tasks which are
>> ready to run are not getting CPU and are queued back.
>
> Something terminally bad happened. With that tasks vruntime (tree-key),
> it's gonna try to yield for one hell of a long time before it succeeds.
>
> -Mike
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sched_yield() call on Linux Kernel 2.6.39 is not behaving correct
2015-01-09 19:24 ` Yogesh Ahire
@ 2015-01-10 7:37 ` Mike Galbraith
0 siblings, 0 replies; 6+ messages in thread
From: Mike Galbraith @ 2015-01-10 7:37 UTC (permalink / raw)
To: Yogesh Ahire; +Cc: linux-kernel
On Fri, 2015-01-09 at 11:24 -0800, Yogesh Ahire wrote:
> Thank you Mike. I didn't get what you mean by saying "its gona try to
> yield for one hell of a long time before it succeeds".
Look at vruntimes. Equalizing same is what the scheduler does for a
living, it does so by giving the CPU to the runnable task with the
lowest vruntime. Exec time is scaled by load to become vruntime, but
this vruntime delta is so large you may as well just call it infinity.
-Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-10 7:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-07 21:30 sched_yield() call on Linux Kernel 2.6.39 is not behaving correct Yogesh Ahire
2015-01-08 5:26 ` Mike Galbraith
2015-01-08 15:00 ` Yogesh Ahire
2015-01-09 3:14 ` Mike Galbraith
2015-01-09 19:24 ` Yogesh Ahire
2015-01-10 7:37 ` Mike Galbraith
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.