All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Anna-Maria Behnsen <anna-maria@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC 1/3] tick-sched: Remove last_tick and calculate next tick from now
Date: Tue, 12 Nov 2024 18:33:30 +0000	[thread overview]
Message-ID: <20241112183330.GA2061573@google.com> (raw)
In-Reply-To: <ZzKWvislBnjV9kpf@pavilion.home>

On Tue, Nov 12, 2024 at 12:43:58AM +0100, Frederic Weisbecker wrote:
> Le Fri, Nov 08, 2024 at 05:48:34PM +0000, Joel Fernandes (Google) a écrit :
> > During tick restart, we use last_tick and forward it past now.
> > 
> > Since we are forwarding past now, we can simply use now as a reference
> > instead of last_tick. This patch removes last_tick and does so.
> > 
> > This patch potentially does more mul/imul than the existing code,
> > as sometimes forwarding past now need not be done if last_tick > now.
> 
> Which is not uncommon if idle exited because of a non-timer interrupt
> (remote wake up IPI or hardware interrupt).
> 
> It's also cheaper with hrtimer_forward() if now - last_tick < TICK_NSEC
> which is not uncommon either if idle exited because of a wake-up from the tick
> (schedule_timeout for example).
> 
> > However, the patch is a cleanup which reduces LOC and reduces the size
> > of struct tick_sched.
> 
> Reducing the overhead of idle exit and consolidating its code within existing
> forward API is more important than a per-cpu field.
> 
> > 
> > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > ---
> >  kernel/time/tick-sched.c | 7 ++-----
> >  kernel/time/tick-sched.h | 1 -
> >  kernel/time/timer_list.c | 1 -
> >  3 files changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 71a792cd8936..52a4eda664cf 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -837,11 +837,9 @@ EXPORT_SYMBOL_GPL(get_cpu_iowait_time_us);
> >  
> >  static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)
> >  {
> > +	/* Set the time to expire on the next tick and not some far away future. */
> >  	hrtimer_cancel(&ts->sched_timer);
> > -	hrtimer_set_expires(&ts->sched_timer, ts->last_tick);
> > -
> > -	/* Forward the time to expire in the future */
> > -	hrtimer_forward(&ts->sched_timer, now, TICK_NSEC);
> > +	hrtimer_set_expires(&ts->sched_timer, DIV_ROUND_UP_ULL(now, TICK_NSEC) * TICK_NSEC);
> 
> We don't want to rewrite hrtimer_forward() but, after all, the current expiry is
> enough a relevant information.

Thanks, do you envision any way we can get past the sched_skew_tick issue
Thomas mentioned, if we still want to do something like this patch?

> How about just this? It's worth it as it now forwards after the real last programmed
> tick, which should be close enough from @now with a delta below TICK_NSEC, or even
> better @now is below the expiry. Therefore it should resume as just a no-op
> or at worst an addition within hrtimer_forward():
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 753a184c7090..ffd0c026a248 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -838,7 +838,6 @@ EXPORT_SYMBOL_GPL(get_cpu_iowait_time_us);
>  static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)
>  {
>  	hrtimer_cancel(&ts->sched_timer);
> -	hrtimer_set_expires(&ts->sched_timer, ts->last_tick);
>  
>  	/* Forward the time to expire in the future */
>  	hrtimer_forward(&ts->sched_timer, now, TICK_NSEC);

For completeness, as we discussed on other thread and Thomas mentioned, we
break code if doing this.

> As for removing last_tick, I think it's a precious debugging information. But
> it's lagging behind the record of the first time only the tick got stopped within
> the last trip to idle. So it could become this instead:
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 753a184c7090..af013f7733b2 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -1042,12 +1041,11 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu)
>  	if (!tick_sched_flag_test(ts, TS_FLAG_STOPPED)) {
>  		calc_load_nohz_start();
>  		quiet_vmstat();
> -
> -		ts->last_tick = hrtimer_get_expires(&ts->sched_timer);
>  		tick_sched_flag_set(ts, TS_FLAG_STOPPED);
>  		trace_tick_stop(1, TICK_DEP_MASK_NONE);
>  	}
>  
> +	ts->last_tick = hrtimer_get_expires(&ts->sched_timer);
>  	ts->next_tick = expires;

Are you suggesting we roll this part of your diff into a new patch (to
improve debug)? I could do that with attribution to you. But I guess I don't
understand this particular part of your diff.

If the tick was already stopped, how does
hrtimer_get_expires(&ts->sched_timer) change since the last time the tick was
stopped? ->last_tick should be set only when the tick was last running and a
stop was attempted? Otherwise your diff might set ->last_tick well into the
future after the tick was already stopped, AFAICS.

thanks,

 - Joel


  parent reply	other threads:[~2024-11-12 18:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 17:48 [RFC 0/3] tick-sched cleanups Joel Fernandes (Google)
2024-11-08 17:48 ` [RFC 1/3] tick-sched: Remove last_tick and calculate next tick from now Joel Fernandes (Google)
2024-11-11 23:43   ` Frederic Weisbecker
2024-11-12 13:46     ` Thomas Gleixner
2024-11-12 13:56       ` Frederic Weisbecker
2024-11-12 18:20       ` Joel Fernandes
2024-11-12 18:33     ` Joel Fernandes [this message]
2024-11-13 12:40       ` Frederic Weisbecker
2024-11-13 21:40         ` Joel Fernandes
2024-11-08 17:48 ` [RFC 2/3] tick-sched: Keep tick on if hrtimer is due imminently Joel Fernandes (Google)
2024-11-11 12:37   ` Christian Loehle
2024-11-11 15:56     ` Joel Fernandes
2024-11-11 16:55       ` Christian Loehle
2024-11-11 17:17         ` Joel Fernandes
2024-11-08 17:48 ` [RFC 3/3] tick-sched: Replace jiffie readout with idle_entrytime Joel Fernandes (Google)
2024-11-10 22:55   ` Joel Fernandes
2024-11-12 14:48     ` Thomas Gleixner
2024-11-13 21:46       ` Joel Fernandes
2024-11-11 22:25   ` Frederic Weisbecker
2024-11-13 22:39     ` Joel Fernandes
2024-11-12 14:30   ` Thomas Gleixner
2024-11-13 22:18     ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241112183330.GA2061573@google.com \
    --to=joel@joelfernandes.org \
    --cc=anna-maria@linutronix.de \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.