Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <xhsmhedy9fsg5.mognet@vschneid.remote.csb> <20220725104356.GA2950296@lothringen>
 <xhsmh5yjlfd97.mognet@vschneid.remote.csb>
In-Reply-To: <xhsmh5yjlfd97.mognet@vschneid.remote.csb>
From:   Arjan van de Ven <arjanvandeven@gmail.com>
Date:   Mon, 25 Jul 2022 08:18:57 -0700
Message-ID: <CADyApD2dBHYW7xx9K-4Pjek+1g+9mUD9Q2KYd1fzE741VKgV7A@mail.gmail.com>
Subject: Re: [Question] timers: trigger_dyntick_cpu() vs TIMER_DEFERRABLE
To:     Valentin Schneider <vschneid@redhat.com>
Cc:     Frederic Weisbecker <frederic@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Arjan van de Ven <arjan@infradead.org>,
        Chris Mason <clm@fb.com>, Eric Dumazet <edumazet@google.com>,
        George Spelvin <linux@sciencehorizons.net>,
        Josh Triplett <josh@joshtriplett.org>,
        Len Brown <lenb@kernel.org>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Rik van Riel <riel@surriel.com>,
        Marcelo Tosatti <mtosatti@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> Ah, that makes sense, thank you for highlighting the difference. The
> comment *does* say "come out of *idle*", not *tickless*...
>
> > Now that's the theory. In practice the deferrable timers are ignored by
> > both nohz-idle and nohz-full when it comes to compute the next nohz delta.
> > This is a mistake that is there since the introduction of nohz-full but I've
> > always been scared to break some user setup while fixing it. Anyway things
> > should look like this (untested):
> >
>
> IIUC that's making get_next_timer_interrupt() poke the deferrable base if the
> CPU isn't tickless idle (IOW if it is tickless "busy" or ticking
> idle). That makes sense from what you've written above, but I get your
> apprehension (though AIUI "only" pinned deferrable timers should be
> problematic, as the others should be migrated away).
>
>


taking a small step back; the idea behind deferrable timers is
(mostly) that these are timers that do ongoing "maintenance" of sorts,
be it counter updates or cleanup or whatever...
and that if the CPU is idle, no things happen that would require such
maintenance... so it's not worth waking the CPU out of idle for it...
and the nature of the timer is such
that delays are benign; sure the counters get sync'd maybe a bit later
but it does not impact correctness.

But once "real code" is executing (we can debate if an occasional
network interrupt counts as such but that's a detail) work is done
that would cause the maintenance to be meaningful again,
and then we do fire these timers "as usual", but ideally grouped with
other timers. So frankly that doesn't mean "right the exact
millisecond", after all the nature of deferrable already means that
exact timing is not implied, but within reason if something else
happens anyway/