tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too

A customer provided some evidence which indicates that the idle tick was stopped; albeit, CPU-specific vmstat counters still remained populated. Thus one can only assume quiet_vmstat() was not invoked on return to the idle loop.

Quoted 4 lines · Aaron Tomlin

A customer provided some evidence which indicates that the idle tick was stopped; albeit, CPU-specific vmstat counters still remained populated. Thus one can only assume quiet_vmstat() was not invoked on return to the idle loop.

Could we *always* fold the vmstat counters when entering idle mode? That would make the logic less complicated. There is nothing else to do since we are entering an idle state and if there are any counter deltas then we have the time to process them. This may also decrease the time that deltas exist significantly and an idle system will have accurate vmstat counters.

Yes, in the context of nohz, this patch should ensure it, if required, when the idle tick is to be stopped.

Quoted 2 lines · Aaron Tomlin

Yes, in the context of nohz, this patch should ensure it, if required, when the idle tick is to be stopped.

What I said was that it is generally useful. Even in the non NOHZ case.

Folding the vmstat diffs *always* when entering idle prevents unnecessary wakeups and processing in the future and also provides more accurate counters for the VM allowing better decision to be made on reclaim.

Quoted 3 lines

Folding the vmstat diffs *always* when entering idle prevents unnecessary wakeups and processing in the future and also provides more accurate counters for the VM allowing better decision to be made on reclaim.

I'm thinking you're going to find a ton of regressions if you try it though; some workloads go idle *very* shortly, doing all this accounting is going to be counter-productive.

It may depend though on how long the idle periods are. Do we have statistics on the duration? Always folding the vmstat deltas may also increase the length of the idle periods.

Quoted 7 lines · Peter Zijlstra

Quoted 3 lines

Folding the vmstat diffs *always* when entering idle prevents unnecessary wakeups and processing in the future and also provides more accurate counters for the VM allowing better decision to be made on reclaim.

I'm thinking you're going to find a ton of regressions if you try it though; some workloads go idle *very* shortly, doing all this accounting is going to be counter-productive.

Well there is usually not much to do in terms of accounting.

If there are
a lot of updates then it is worthwhile because if the numbers are off too much then the VM has trouble assessing its own situation.

It may depend though on how long the idle periods are. Do we have statistics on the duration? Always folding the vmstat deltas may also increase the length of the idle periods.

Quoted 7 lines · Christoph Lameter

Quoted 2 lines · Aaron Tomlin

Yes, in the context of nohz, this patch should ensure it, if required, when the idle tick is to be stopped.

What I said was that it is generally useful. Even in the non NOHZ case.

Quoted 3 lines

Folding the vmstat diffs *always* when entering idle prevents unnecessary wakeups and processing in the future and also provides more accurate counters for the VM allowing better decision to be made on reclaim.

I'm thinking you're going to find a ton of regressions if you try it though; some workloads go idle *very* shortly, doing all this accounting is going to be counter-productive.

Quoted 8 lines · Peter Zijlstra

Quoted 7 lines · Christoph Lameter

Quoted 2 lines · Aaron Tomlin

Yes, in the context of nohz, this patch should ensure it, if required, when the idle tick is to be stopped.

What I said was that it is generally useful. Even in the non NOHZ case.

Quoted 7 lines

Quoted 3 lines

Folding the vmstat diffs *always* when entering idle prevents unnecessary wakeups and processing in the future and also provides more accurate counters for the VM allowing better decision to be made on reclaim.

I'm thinking you're going to find a ton of regressions if you try it though; some workloads go idle *very* shortly, doing all this accounting is going to be counter-productive.

Hi Peter, Christoph,

Indeed. Which was why I decided, initially, against the general-purpose case/or approach. Personally, I would prefer to keep this somewhat restrictive to nohz.

Quoted 5 lines

Hi Peter, Christoph,

Indeed. Which was why I decided, initially, against the general-purpose case/or approach. Personally, I would prefer to keep this somewhat restrictive to nohz.

Is there anything that prevents a nohz full CPU from running an application with short and frequent idling?

Quoted 2 lines · Marcelo Tosatti

Is there anything that prevents a nohz full CPU from running an application with short and frequent idling?

I'm not sure I understand the question; albeit, if I understand correctly,
yes: the scheduling-clock tick, if it was stopped.
Yet I believe this behaviour is correct. Consider the following example:

When a CFS task is moved/or migrated to a nohz_full CPU that was previously idle and had its tick stopped, if its the only task on the run-queue then it is possible that the idle task may not restart the tick (see __tick_nohz_full_update_tick()). Thus once the CFS task exits manual intervention i.e. a reschedule IPI to wake the idle task, would be required to run again, on the same CPU.

Quoted 8 lines · Aaron Tomlin

Quoted 2 lines · Marcelo Tosatti

Is there anything that prevents a nohz full CPU from running an application with short and frequent idling?

I'm not sure I understand the question; albeit, if I understand correctly,
yes: the scheduling-clock tick, if it was stopped.
Yet I believe this behaviour is correct. Consider the following example:

Quoted 6 lines

When a CFS task is moved/or migrated to a nohz_full CPU that was previously idle and had its tick stopped, if its the only task on the run-queue then it is possible that the idle task may not restart the tick (see __tick_nohz_full_update_tick()). Thus once the CFS task exits manual intervention i.e. a reschedule IPI to wake the idle task, would be required to run again, on the same CPU.

When the task exits and the tick was stopped, why should idle restart the tick? There is nothing to do, so what?

Hi Frederic and Marcelo,

Oops, please ignore RFC Patch v2 [1] since I forgot to compile test - sorry about that! Any feedback would be appreciated. Thanks.

[1]: https://lore.kernel.org/lkml/[email protected]/

In the context of the idle task and an adaptive-tick mode/or a nohz_full CPU, quiet_vmstat() can be called: before stopping the idle tick, entering an idle state and on exit. In particular, for the latter case, when the idle task is required to reschedule, the idle tick can remain stopped and the timer expiration time endless i.e., KTIME_MAX. Now, indeed before a nohz_full CPU enters an idle state, CPU-specific vmstat counters should be processed to ensure the respective values have been reset and folded into the zone specific 'vm_stat[]'. That being said, it can only occur when: the idle tick was previously stopped, and reprogramming of the timer is not required.

A customer provided some evidence which indicates that the idle tick was stopped; albeit, CPU-specific vmstat counters still remained populated. Thus one can only assume quiet_vmstat() was not invoked on return to the idle loop.

If I understand correctly, I suspect this divergence might erroneously prevent a reclaim attempt by kswapd. If the number of zone specific free pages are below their per-cpu drift value then zone_page_state_snapshot() is used to compute a more accurate view of the aforementioned statistic. Thus any task blocked on the NUMA node specific pfmemalloc_wait queue will be unable to make significant progress via direct reclaim unless it is killed after being woken up by kswapd (see throttle_direct_reclaim()).

Consider the following theoretical scenario:

1. CPU Y migrated running task A to CPU X that was
in an idle state i.e. waiting for an IRQ - not polling; marked the current task on CPU X to need/or require a reschedule i.e., set TIF_NEED_RESCHED and invoked a reschedule IPI to CPU X (see sched_move_task())

2. CPU X acknowledged the reschedule IPI from CPU Y;
generic idle loop code noticed the TIF_NEED_RESCHED flag against the idle task and attempts to exit of the loop and calls the main scheduler function i.e. __schedule().

Since the idle tick was previously stopped no scheduling-clock tick would occur. So, no deferred timers would be handled

3. Post transition to kernel execution Task A
running on CPU Y, indirectly released a few pages (e.g. see __free_one_page()); CPU Y's 'vm_stat_diff[NR_FREE_PAGES]' was updated and zone specific 'vm_stat[]' update was deferred as per the CPU-specific stat threshold

4. Task A does invoke exit(2) and the kernel does
remove the task from the run-queue; the idle task was selected to execute next since there are no other runnable tasks assigned to the given CPU (see pick_next_task() and pick_next_task_idle())

5. On return to the idle loop since the idle tick
was already stopped and can remain so (see [1] below) e.g. no pending soft IRQs, no attempt is made to zero and fold CPU Y's vmstat counters since reprogramming of the scheduling-clock tick is not required/or needed (see [2])

...
do_idle
{

__current_set_polling()
tick_nohz_idle_enter()

while (!need_resched()) {

local_irq_disable()

...

/* No polling or broadcast event */ cpuidle_idle_call()
{

if (cpuidle_not_available(drv, dev)) {
tick_nohz_idle_stop_tick()
__tick_nohz_idle_stop_tick(this_cpu_ptr(&tick_cpu_sched)) {
int cpu = smp_processor_id()

if (ts->timer_expires_base)
expires = ts->timer_expires
else if (can_stop_idle_tick(cpu, ts))
(1) -------> expires = tick_nohz_next_event(ts, cpu)
else
return

ts->idle_calls++

if (expires > 0LL) {

tick_nohz_stop_tick(ts, cpu) {

if (ts->tick_stopped && (expires == ts->next_tick)) {
(2) -------> if (tick == KTIME_MAX || ts->next_tick ==
hrtimer_get_expires(&ts->sched_timer)) return
}
...
}

So the idea of with this patch is to ensure refresh_cpu_vm_stats(false) is called, when it is appropriate, on return to the idle loop when the idle tick was previously stopped too. Additionally, when the scheduling-tick is stopped and a task in kernel-mode, modifies the CPU-specific 'vm_stat_diff[]' and goes to user-mode for a long time.

Signed-off-by Aaron Tomlin <[email protected]>

---
 include/linux/tick.h     |  9 ++-------
 kernel/time/tick-sched.c | 18 +++++++++++++++++-
 2 files changed, 19 insertions(+), 8 deletions(-)

include/linux/tick.h +2 -7

index bfd571f18cfd..4c576c9ca0a2 100644
@@ -11,7 +11,6 @@
 #include <linux/context_tracking_state.h>
 #include <linux/cpumask.h>
 #include <linux/sched.h>
-#include <linux/rcupdate.h>
 
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
 extern void __init tick_init(void);

@@ -123,6 +122,8 @@ enum tick_dep_bits {
 #define TICK_DEP_MASK_RCU		(1 << TICK_DEP_BIT_RCU)
 #define TICK_DEP_MASK_RCU_EXP		(1 << TICK_DEP_BIT_RCU_EXP)
 
+void tick_nohz_user_enter_prepare(void);
+
 #ifdef CONFIG_NO_HZ_COMMON
 extern bool tick_nohz_enabled;
 extern bool tick_nohz_tick_stopped(void);

@@ -305,10 +306,4 @@ static inline void tick_nohz_task_switch(void)
 		__tick_nohz_task_switch();
 }
 
-static inline void tick_nohz_user_enter_prepare(void)
-{
-	if (tick_nohz_full_cpu(smp_processor_id()))
-		rcu_nocb_flush_deferred_wakeup();
-}
-
 #endif

kernel/time/tick-sched.c +3 -0

index d257721c68b8..c6cac2d8e8ed 100644
@@ -26,6 +26,7 @@
 #include <linux/posix-timers.h>
 #include <linux/context_tracking.h>
 #include <linux/mm.h>
+#include <linux/rcupdate.h>
 
 #include <asm/irq_regs.h>
 

@@ -43,6 +44,19 @@ struct tick_sched *tick_get_tick_sched(int cpu)
 	return &per_cpu(tick_cpu_sched, cpu);
 }
 
+void tick_nohz_user_enter_prepare(void)
+{

kernel/time/tick-sched.c +4 -1

+
 #if defined(CONFIG_NO_HZ_COMMON) || defined(CONFIG_HIGH_RES_TIMERS)
 /*
  * The time, when the last jiffy update happened. Write access must hold

@@ -891,6 +905,9 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu)
 		ts->do_timer_last = 0;
 	}
 
+	/* Attempt to fold when the idle tick is stopped or not */
+	quiet_vmstat();
+
 	/* Skip reprogram of event if its not changed */
 	if (ts->tick_stopped && (expires == ts->next_tick)) {
 		/* Sanity check: make sure clockevent is actually programmed */

@@ -912,7 +929,6 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu)
 	 */
 	if (!ts->tick_stopped) {
 		calc_load_nohz_start();
-		quiet_vmstat();
 
 		ts->last_tick = hrtimer_get_expires(&ts->sched_timer);
 		ts->tick_stopped = 1;

Signature · 1 line

2.34.1

So you are syncing the vmstats on every system call return:

Have you measured performance of any system call heavy application with this change?

Then the comment on why its so slow:

"This loop is quite heavy. Maybe reducing the data necessary to be read to a couple of cachelines would improve it considerably."

The comment:

"Is there anything that prevents a nohz full CPU from running an application with short and frequent idling?"

Is confusing and can be ignored.