All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
@ 2022-04-22 19:36 Aaron Tomlin
  2022-04-25  7:23 ` Christoph Lameter
  2022-04-28 18:10 ` Marcelo Tosatti
  0 siblings, 2 replies; 15+ messages in thread
From: Aaron Tomlin @ 2022-04-22 19:36 UTC (permalink / raw)
  To: frederic, mtosatti
  Cc: cl, tglx, mingo, peterz, pauld, neelx, oleksandr, linux-kernel, linux-mm

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/20220422112053.3695526-1-atomlin@redhat.com/


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 <atomlin@redhat.com>
---
 include/linux/tick.h     |  9 ++-------
 kernel/time/tick-sched.c | 18 +++++++++++++++++-
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/include/linux/tick.h b/include/linux/tick.h
index bfd571f18cfd..4c576c9ca0a2 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -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
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index d257721c68b8..c6cac2d8e8ed 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -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)
+{
+	struct tick_sched *ts;
+
+	if (tick_nohz_full_cpu(smp_processor_id())) {
+		ts = this_cpu_ptr(&tick_cpu_sched);
+
+		if (ts->tick_stopped)
+			quiet_vmstat();
+		rcu_nocb_flush_deferred_wakeup();
+	}
+}
+
 #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;
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-22 19:36 [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too Aaron Tomlin
@ 2022-04-25  7:23 ` Christoph Lameter
  2022-04-25 11:39   ` Aaron Tomlin
  2022-04-28 18:10 ` Marcelo Tosatti
  1 sibling, 1 reply; 15+ messages in thread
From: Christoph Lameter @ 2022-04-25  7:23 UTC (permalink / raw)
  To: Aaron Tomlin
  Cc: frederic, mtosatti, tglx, mingo, peterz, pauld, neelx, oleksandr,
	linux-kernel, linux-mm

On Fri, 22 Apr 2022, Aaron Tomlin wrote:

> 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25  7:23 ` Christoph Lameter
@ 2022-04-25 11:39   ` Aaron Tomlin
  2022-04-25 12:09     ` Christoph Lameter
  0 siblings, 1 reply; 15+ messages in thread
From: Aaron Tomlin @ 2022-04-25 11:39 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: frederic, mtosatti, tglx, mingo, peterz, pauld, neelx, oleksandr,
	linux-kernel, linux-mm

On Mon 2022-04-25 09:23 +0200, Christoph Lameter wrote:
> On Fri, 22 Apr 2022, Aaron Tomlin wrote:
> 
> > 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.

Hi Christoph,

Thank you for your feedback.

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


Kind regards,

-- 
Aaron Tomlin


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 11:39   ` Aaron Tomlin
@ 2022-04-25 12:09     ` Christoph Lameter
  2022-04-25 13:27       ` Peter Zijlstra
  0 siblings, 1 reply; 15+ messages in thread
From: Christoph Lameter @ 2022-04-25 12:09 UTC (permalink / raw)
  To: Aaron Tomlin
  Cc: frederic, mtosatti, tglx, mingo, peterz, pauld, neelx, oleksandr,
	linux-kernel, linux-mm

On Mon, 25 Apr 2022, Aaron Tomlin wrote:

> 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.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 12:09     ` Christoph Lameter
@ 2022-04-25 13:27       ` Peter Zijlstra
  2022-04-25 14:06         ` Christoph Lameter
  2022-04-25 14:17         ` Aaron Tomlin
  0 siblings, 2 replies; 15+ messages in thread
From: Peter Zijlstra @ 2022-04-25 13:27 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Aaron Tomlin, frederic, mtosatti, tglx, mingo, pauld, neelx,
	oleksandr, linux-kernel, linux-mm

On Mon, Apr 25, 2022 at 02:09:06PM +0200, Christoph Lameter wrote:
> On Mon, 25 Apr 2022, Aaron Tomlin wrote:
> 
> > 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.

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 13:27       ` Peter Zijlstra
@ 2022-04-25 14:06         ` Christoph Lameter
  2022-04-25 14:51           ` Aaron Tomlin
  2022-04-25 14:57           ` Marcelo Tosatti
  2022-04-25 14:17         ` Aaron Tomlin
  1 sibling, 2 replies; 15+ messages in thread
From: Christoph Lameter @ 2022-04-25 14:06 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Aaron Tomlin, frederic, mtosatti, tglx, mingo, pauld, neelx,
	oleksandr, linux-kernel, linux-mm

On Mon, 25 Apr 2022, Peter Zijlstra wrote:

> > 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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 13:27       ` Peter Zijlstra
  2022-04-25 14:06         ` Christoph Lameter
@ 2022-04-25 14:17         ` Aaron Tomlin
  2022-04-25 19:21           ` Marcelo Tosatti
  1 sibling, 1 reply; 15+ messages in thread
From: Aaron Tomlin @ 2022-04-25 14:17 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Christoph Lameter, frederic, mtosatti, tglx, mingo, pauld, neelx,
	oleksandr, linux-kernel, linux-mm

On Mon 2022-04-25 15:27 +0200, Peter Zijlstra wrote:
> On Mon, Apr 25, 2022 at 02:09:06PM +0200, Christoph Lameter wrote:
> > On Mon, 25 Apr 2022, Aaron Tomlin wrote:
> > 
> > > 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.
> 
> 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.


Kind regards,

-- 
Aaron Tomlin


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 14:06         ` Christoph Lameter
@ 2022-04-25 14:51           ` Aaron Tomlin
  2022-04-25 14:57           ` Marcelo Tosatti
  1 sibling, 0 replies; 15+ messages in thread
From: Aaron Tomlin @ 2022-04-25 14:51 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Peter Zijlstra, frederic, mtosatti, tglx, mingo, pauld, neelx,
	oleksandr, linux-kernel, linux-mm

On Mon 2022-04-25 16:06 +0200, Christoph Lameter wrote:
> 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.

Unfortunately I do not. I noticed that this situation can occur via source
code and vmcore analysis.


Kind regards,

-- 
Aaron Tomlin


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 14:06         ` Christoph Lameter
  2022-04-25 14:51           ` Aaron Tomlin
@ 2022-04-25 14:57           ` Marcelo Tosatti
  1 sibling, 0 replies; 15+ messages in thread
From: Marcelo Tosatti @ 2022-04-25 14:57 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Peter Zijlstra, Aaron Tomlin, frederic, tglx, mingo, pauld,
	neelx, oleksandr, linux-kernel, linux-mm

On Mon, Apr 25, 2022 at 04:06:04PM +0200, Christoph Lameter wrote:
> On Mon, 25 Apr 2022, Peter Zijlstra wrote:
> 
> > > 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. 

static int refresh_cpu_vm_stats(bool do_pagesets)
{
        struct pglist_data *pgdat;
        struct zone *zone;
        int i;
        int global_zone_diff[NR_VM_ZONE_STAT_ITEMS] = { 0, };
        int global_node_diff[NR_VM_NODE_STAT_ITEMS] = { 0, };
        int changes = 0;

        for_each_populated_zone(zone) {
                struct per_cpu_zonestat __percpu *pzstats = zone->per_cpu_zonestats;
#ifdef CONFIG_NUMA
                struct per_cpu_pages __percpu *pcp = zone->per_cpu_pageset;
#endif

                for (i = 0; i < NR_VM_ZONE_STAT_ITEMS; i++) {
                        int v;

                        v = this_cpu_xchg(pzstats->vm_stat_diff[i], 0);
                        if (v) {

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

> 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.

"Products such as the Intel® Optane™ SSD DC P4800X series have a read and write
latency of 10 microseconds, compared with a write latency of about 220 
microseconds for a typical NAND flash SSD."



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 14:17         ` Aaron Tomlin
@ 2022-04-25 19:21           ` Marcelo Tosatti
  2022-04-27 11:50             ` Aaron Tomlin
  0 siblings, 1 reply; 15+ messages in thread
From: Marcelo Tosatti @ 2022-04-25 19:21 UTC (permalink / raw)
  To: Aaron Tomlin
  Cc: Peter Zijlstra, Christoph Lameter, frederic, tglx, mingo, pauld,
	neelx, oleksandr, linux-kernel, linux-mm

On Mon, Apr 25, 2022 at 03:17:17PM +0100, Aaron Tomlin wrote:
> On Mon 2022-04-25 15:27 +0200, Peter Zijlstra wrote:
> > On Mon, Apr 25, 2022 at 02:09:06PM +0200, Christoph Lameter wrote:
> > > On Mon, 25 Apr 2022, Aaron Tomlin wrote:
> > > 
> > > > 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.
> > 
> > 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.

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

Note:

commit a5183862e76fdc25f36b39c2489b816a5c66e2e5
Author: Yunfeng Ye <yeyunfeng@huawei.com>
Date:   Thu May 13 01:29:16 2021 +0200

    tick/nohz: Conditionally restart tick on idle exit
    
    In nohz_full mode, switching from idle to a task will unconditionally
    issue a tick restart. If the task is alone in the runqueue or is the
    highest priority, the tick will fire once then eventually stop. But that
    alone is still undesired noise.
    
    Therefore, only restart the tick on idle exit when it's strictly
    necessary.
    
    Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20210512232924.150322-3-frederic@kernel.org



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-25 19:21           ` Marcelo Tosatti
@ 2022-04-27 11:50             ` Aaron Tomlin
  2022-04-27 14:40               ` Thomas Gleixner
  0 siblings, 1 reply; 15+ messages in thread
From: Aaron Tomlin @ 2022-04-27 11:50 UTC (permalink / raw)
  To: Marcelo Tosatti
  Cc: Peter Zijlstra, Christoph Lameter, frederic, tglx, mingo, pauld,
	neelx, oleksandr, linux-kernel, linux-mm

On Mon 2022-04-25 16:21 -0300, Marcelo Tosatti wrote:
> > 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?

Hi Marcelo,

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.



Kind regards,

-- 
Aaron Tomlin


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-27 11:50             ` Aaron Tomlin
@ 2022-04-27 14:40               ` Thomas Gleixner
  2022-04-27 14:49                 ` Aaron Tomlin
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas Gleixner @ 2022-04-27 14:40 UTC (permalink / raw)
  To: Aaron Tomlin, Marcelo Tosatti
  Cc: Peter Zijlstra, Christoph Lameter, frederic, mingo, pauld, neelx,
	oleksandr, linux-kernel, linux-mm

On Wed, Apr 27 2022 at 12:50, Aaron Tomlin wrote:
> On Mon 2022-04-25 16:21 -0300, Marcelo Tosatti wrote:
>> 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.

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

Thanks,

        tglx


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-27 14:40               ` Thomas Gleixner
@ 2022-04-27 14:49                 ` Aaron Tomlin
  0 siblings, 0 replies; 15+ messages in thread
From: Aaron Tomlin @ 2022-04-27 14:49 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Marcelo Tosatti, Peter Zijlstra, Christoph Lameter, frederic,
	mingo, pauld, neelx, oleksandr, linux-kernel, linux-mm

On Wed 2022-04-27 16:40 +0200, Thomas Gleixner wrote:
> On Wed, Apr 27 2022 at 12:50, Aaron Tomlin wrote:
> > On Mon 2022-04-25 16:21 -0300, Marcelo Tosatti wrote:
> >> 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.
> 
> When the task exits and the tick was stopped, why should idle restart
> the tick? There is nothing to do, so what?

Hi Thomas,

Indeed. As per my response, I do not see an issue. Perhaps I misunderstood
Marcelo's question, no?

Kind regards,

-- 
Aaron Tomlin


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-22 19:36 [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too Aaron Tomlin
  2022-04-25  7:23 ` Christoph Lameter
@ 2022-04-28 18:10 ` Marcelo Tosatti
  2022-05-04  9:32   ` Aaron Tomlin
  1 sibling, 1 reply; 15+ messages in thread
From: Marcelo Tosatti @ 2022-04-28 18:10 UTC (permalink / raw)
  To: Aaron Tomlin
  Cc: frederic, cl, tglx, mingo, peterz, pauld, neelx, oleksandr,
	linux-kernel, linux-mm

On Fri, Apr 22, 2022 at 08:36:47PM +0100, Aaron Tomlin wrote:
> 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/20220422112053.3695526-1-atomlin@redhat.com/
> 
> 
> 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 <atomlin@redhat.com>
> ---
>  include/linux/tick.h     |  9 ++-------
>  kernel/time/tick-sched.c | 18 +++++++++++++++++-
>  2 files changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index bfd571f18cfd..4c576c9ca0a2 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -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
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index d257721c68b8..c6cac2d8e8ed 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -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)
> +{
> +	struct tick_sched *ts;
> +
> +	if (tick_nohz_full_cpu(smp_processor_id())) {
> +		ts = this_cpu_ptr(&tick_cpu_sched);
> +
> +		if (ts->tick_stopped)
> +			quiet_vmstat();
> +		rcu_nocb_flush_deferred_wakeup();
> +	}
> +}

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

static void exit_to_user_mode_prepare(struct pt_regs *regs)
{
        unsigned long ti_work = read_thread_flags();
        
        lockdep_assert_irqs_disabled();

        /* Flush pending rcuog wakeup before the last need_resched() check */
        tick_nohz_user_enter_prepare();

As PeterZ mentioned for idle (which can be very frequent), returning 
to userspace can be very frequent as well. 

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

From my experience with the task isolation patchset, it will cause
noticeable slowdown to system call return.

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.

> +
>  #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;
> -- 
> 2.34.1
> 
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too
  2022-04-28 18:10 ` Marcelo Tosatti
@ 2022-05-04  9:32   ` Aaron Tomlin
  0 siblings, 0 replies; 15+ messages in thread
From: Aaron Tomlin @ 2022-05-04  9:32 UTC (permalink / raw)
  To: Marcelo Tosatti
  Cc: frederic, cl, tglx, mingo, peterz, pauld, neelx, oleksandr,
	linux-kernel, linux-mm

On Thu 2022-04-28 15:10 -0300, Marcelo Tosatti wrote:
> So you are syncing the vmstats on every system call return:

Hi Marcelo,

Sorry about the delay!

No - indeed, that would be too expensive. If I understand correctly,
Peter Zijlstra's feedback was in response to a previous suggestion made:

	"Could we *always* fold the vmstat counters when entering
	 idle mode? ..."

I think an exception should be made for the adaptive-tick mode/or a
nohz_full CPU case when the scheduling-clock tick is stopped. Also, I feel
correctness is key, as previously indicated since a significant divergence
can impact memory reclaim code.

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

Unfortunately not. That being said, the aforementioned test and work will
only take place under a nohz_full CPU and if the tick is stopped.
So this should be somewhat limited, no?

> 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.

Understood.



Kind regards,

-- 
Aaron Tomlin


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-05-04  9:38 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-22 19:36 [RFC PATCH v3] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too Aaron Tomlin
2022-04-25  7:23 ` Christoph Lameter
2022-04-25 11:39   ` Aaron Tomlin
2022-04-25 12:09     ` Christoph Lameter
2022-04-25 13:27       ` Peter Zijlstra
2022-04-25 14:06         ` Christoph Lameter
2022-04-25 14:51           ` Aaron Tomlin
2022-04-25 14:57           ` Marcelo Tosatti
2022-04-25 14:17         ` Aaron Tomlin
2022-04-25 19:21           ` Marcelo Tosatti
2022-04-27 11:50             ` Aaron Tomlin
2022-04-27 14:40               ` Thomas Gleixner
2022-04-27 14:49                 ` Aaron Tomlin
2022-04-28 18:10 ` Marcelo Tosatti
2022-05-04  9:32   ` Aaron Tomlin

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.