linux-kernel - Re: [PATCH 3/3] tick/nohz: Don't shutdown the lowres tick from itself

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D077B8C8-41EB-4643-99A7-CA54F314218F@joelfernandes.org>
Date:   Sat, 15 Jul 2023 18:31:24 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] tick/nohz: Don't shutdown the lowres tick from itself



> On Jul 15, 2023, at 2:19 PM, Frederic Weisbecker <frederic@...nel.org> wrote:
> 
> On Fri, Jul 14, 2023 at 09:02:43PM -0400, Joel Fernandes wrote:
>>> On Fri, Jul 14, 2023 at 8:01 PM Frederic Weisbecker <frederic@...nel.org> wrote:
>>> 
>>> On Fri, Jul 14, 2023 at 02:44:49PM -0400, Joel Fernandes wrote:
>>>> On 7/14/23 08:08, Frederic Weisbecker wrote:
>>>> One slight concern here though, where in the idle loop is the removed
>>>> statement "tick_program_event(KTIME_MAX, 1);" happening if the tick was
>>>> already stopped before? If it is happening in tick_nohz_stop_tick(), don't
>>>> we early return from there and avoid doing that
>>>> "tick_program_event(KTIME_MAX, 1);" altogether, if the tick was already
>>>> stopped and the next event has not changed?
>>>> 
>>>>        /* Skip reprogram of event if its not changed */
>>>>        if (ts->tick_stopped && (expires == ts->next_tick)) {
>>>>                /* Sanity check: make sure clockevent is actually programmed */
>>>>                if (tick == KTIME_MAX || ts->next_tick ==  [...]
>>>>                        return;
>>>>              [...]
>>>>      }
>>> 
>>> Sure, if tick_program_event(KTIME_MAX, 1) was already called in the
>>> previous idle loop iteration, then there is no need to call that again.
>>> 
>>> Or am I missing something else?
>> 
>> Just take it with a grain of salt but I think you need to still call
>> tick_program_event(KTIME_MAX, 1) here for the case where the tick was
>> previously stopped, and then when the next tick fires (say after a
>> long time T), but that tick is a one-off and does not result in
>> restarting the tick -- then there is no one to call
>> "tick_program_event(KTIME_MAX, 1)".
> 
> I'm a bit confused about that one-off thing. What can trigger that timer
> interrupt if it has been stopped?

It is the tick that has been stopped in this scenario.
The timer could still be armed to serve a future hrtimer?

I think the naming in the code for is a bit confusing for tick vs timer event,
so I could be the confused one.

Thanks,

 - Joel


> One thing can happen though: a pending timer IRQ while we are stopping the
> tick (IRQs are disabled in that idle loop portion). But then that pending timer
> interrupt is not going to reprogram another one. So it remains stopped.
> 
> Thanks.