Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210611103937.827565-1-ani@anisinha.ca> <878s36e0yx.ffs@nanos.tec.linutronix.de>
In-Reply-To: <878s36e0yx.ffs@nanos.tec.linutronix.de>
From:   Ani Sinha <ani@anisinha.ca>
Date:   Sat, 19 Jun 2021 13:48:56 +0530
Message-ID: <CAARzgwy=LY_LfLgsk+KCxr7VxXAzv=FpUMxpW=UNPGWd20X86g@mail.gmail.com>
Subject: Re: [PATCH] Add missing kernel log when enabling NO_HZ_FULL is not possible
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Frederic Weisbecker <fweisbec@gmail.com>,
        Ingo Molnar <mingo@kernel.org>, anirban.sinha@nokia.com,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Jun 19, 2021 at 1:32 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Ani,
>
> On Fri, Jun 11 2021 at 16:09, Ani Sinha wrote:
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 828b091501ca..a82480c036e2 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -937,10 +937,18 @@ static void tick_nohz_full_update_tick(struct tick_sched *ts)
> >       if (!ts->tick_stopped && ts->nohz_mode == NOHZ_MODE_INACTIVE)
> >               return;
> >
> > -     if (can_stop_full_tick(cpu, ts))
> > +     if (can_stop_full_tick(cpu, ts)) {
> >               tick_nohz_stop_sched_tick(ts, cpu);
> > -     else if (ts->tick_stopped)
> > -             tick_nohz_restart_sched_tick(ts, ktime_get());
> > +     } else {
> > +             /*
> > +              * Don't allow the user to think they can get
> > +              * full NO_HZ with this machine.
> > +              */
> > +             WARN_ONCE(tick_nohz_full_running,
> > +                       "NO_HZ_FULL will not work with current sched clock");
>
> How is that warning useful and even remotely correct?
>
> can_stop_full_tick() has 4 x 5 == 20 ways to return false and the
> smaller portion of them is related to sched clock.


Ok I admit I don't fully understand all the sched dep bits. There are
two ways we can solve this. Either we adjust the log message to
reflect that no hz cannot be enabled on this system in general or we
can specifically isolate the conditions that check for sched clock and
for those we add the warning message. Personally, I think we need some
kind of information on the kernel log when no hz enabling is not
possible. Silently disabling it can and did cause confusion that no hz
works fine ( particularly when the older kernel did produce the
warning). I am inclined towards keeping the log where it is but making
it more general and not specific to sched clock.

Ani