Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1269180 > unrolled thread
| Started by | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| First post | 2015-11-13 21:00 +0100 |
| Last post | 2015-11-13 23:30 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH 2/4] timer: relax tick stop in idle entry Jacob Pan <jacob.jun.pan@linux.intel.com> - 2015-11-13 21:00 +0100
Re: [PATCH 2/4] timer: relax tick stop in idle entry Thomas Gleixner <tglx@linutronix.de> - 2015-11-13 21:30 +0100
Re: [PATCH 2/4] timer: relax tick stop in idle entry Jacob Pan <jacob.jun.pan@linux.intel.com> - 2015-11-13 23:30 +0100
| From | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| Date | 2015-11-13 21:00 +0100 |
| Subject | [PATCH 2/4] timer: relax tick stop in idle entry |
| Message-ID | <qusFP-2eI-1@gated-at.bofh.it> |
Upon entering idle, we can turn off tick if the next timeout
is exactly one tick away. Otherwise, we could enter inner idle loop
with tick still enabled, without resched set, the tick will continue
during idle therefore less optimal in terms of energy savings.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 7c7ec45..bcadaab 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -606,7 +606,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
* restart it proper.
*/
delta = next_tick - basemono;
- if (delta <= (u64)TICK_NSEC) {
+ if (delta < (u64)TICK_NSEC) {
tick.tv64 = 0;
if (!ts->tick_stopped)
goto out;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2015-11-13 21:30 +0100 |
| Message-ID | <qut8T-2FM-15@gated-at.bofh.it> |
| In reply to | #1269180 |
On Fri, 13 Nov 2015, Jacob Pan wrote: > Upon entering idle, we can turn off tick if the next timeout > is exactly one tick away. Otherwise, we could enter inner idle loop > with tick still enabled, without resched set, the tick will continue > during idle therefore less optimal in terms of energy savings. This does not make any sense at all. next_tick is the next required tick event. If it's exactly ONE tick away why should we go through the hassle of stopping it? Just to cancel the timer and then set it to the same value again? Oh well. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Jacob Pan <jacob.jun.pan@linux.intel.com> |
|---|---|
| Date | 2015-11-13 23:30 +0100 |
| Message-ID | <quv0Z-3RA-11@gated-at.bofh.it> |
| In reply to | #1269200 |
On Fri, 13 Nov 2015 15:22:16 -0500 (EST)
Thomas Gleixner <tglx@linutronix.de> wrote:
>
>
> On Fri, 13 Nov 2015, Jacob Pan wrote:
>
> > Upon entering idle, we can turn off tick if the next timeout
> > is exactly one tick away. Otherwise, we could enter inner idle loop
> > with tick still enabled, without resched set, the tick will continue
> > during idle therefore less optimal in terms of energy savings.
>
> This does not make any sense at all.
>
> next_tick is the next required tick event. If it's exactly ONE tick
> away why should we go through the hassle of stopping it? Just to
> cancel the timer and then set it to the same value again? Oh well.
>
I have been trying to understand this code, please help. Here is my theory
and the ftrace of an injection period where tick did not stop.
(sorry about the long lines). My comments are after [JP]
cat-1993 [000] 30.093405: sched_cfs_idle_inject: action:0 throttled:1
[JP] injection timer expired, set forced idle flag, call scheduler
cat-1993 [000] 30.093406: hrtimer_expire_exit: hrtimer=0xffff88003de0cc20
cat-1993 [000] 30.093406: hrtimer_start: hrtimer=0xffff88003de0cc20 function=idle_inject_timer_fn/0x0 expires=29993055250 softexpires=29993055250
cat-1993 [000] 30.093407: hrtimer_cancel: hrtimer=0xffff88003dfce400
cat-1993 [000] 30.093407: hrtimer_expire_entry: hrtimer=0xffff88003dfce400 now=29988042960 function=tick_sched_timer/0x0
cat-1993 [000] 30.093407: function: tick_sched_timer
cat-1993 [000] 30.093422: function: tick_sched_do_timer
cat-1993 [000] 30.093422: function: tick_do_update_jiffies64
cat-1993 [000] 30.093433: function: tick_sched_handle.isra.15
cat-1993 [000] 30.093447: sched_stat_runtime: comm=cat pid=1993 runtime=1058498 [ns] vruntime=6695549826 [ns]
cat-1993 [000] 30.093449: hrtimer_expire_exit: hrtimer=0xffff88003dfce400
cat-1993 [000] 30.093449: hrtimer_start: hrtimer=0xffff88003dfce400 function=tick_sched_timer/0x0 expires=29989000000 softexpires=29989000000
cat-1993 [000] 30.093450: function: tick_program_event
cat-1993 [000] 30.093460: sched_waking: comm=rcu_preempt pid=7 prio=120 target_cpu=002
cat-1993 [000] 30.093461: sched_wake_idle_without_ipi: cpu=2
cat-1993 [000] 30.093463: sched_cfs_idle_inject: action:1 throttled:1
[JP] CFS pick_next_task_fair sees forced idle, pick no task to run.
cat-1993 [000] 30.093463: sched_stat_runtime: comm=cat pid=1993 runtime=16122 [ns] vruntime=6695565948 [ns]
cat-1993 [000] 30.093464: sched_switch: cat:1993 [120] R ==> swapper/0:0 [120]
<idle>-0 [000] 30.093465: function: tick_nohz_idle_enter
<idle>-0 [000] 30.093473: bprint: __tick_nohz_idle_enter: JPAN: __tick_nohz_idle_enter 803
<idle>-0 [000] 30.093473: bprint: __tick_nohz_idle_enter: JPAN: can_stop_idle_tick 743
[JP] can_stop_idle_tick() checks ok to stop tick
<idle>-0 [000] 30.093474: bprint: __tick_nohz_idle_enter: JPAN: tick_nohz_stop_sched_tick 609 delta 1000000
[JP] but sees delta is exactly 1 tick away. didn't stop tick.
<idle>-0 [000] 30.093475: function: tick_check_broadcast_expired
<idle>-0 [000] 30.094366: function: tick_irq_enter
<idle>-0 [000] 30.094367: function: tick_check_oneshot_broadcast_this_cpu
<idle>-0 [000] 30.094372: function: tick_nohz_stop_idle
<idle>-0 [000] 30.094387: hrtimer_cancel:
hrtimer=0xffff88003dfce400
[JP] enter repeated tick sched in inner idle loop since !need_resched()
> Thanks,
>
> tglx
>
>
[Jacob Pan]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web