[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACPK8XcOqdtGyJ+Fcan=AaHiJTOZFeUW7-j_5kZeQowr-j24Ag@mail.gmail.com>
Date: Thu, 5 Nov 2020 23:44:11 +0000
From: Joel Stanley <joel@....id.au>
To: Pavel Machek <pavel@....cz>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
stable@...r.kernel.org,
"Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>,
Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH 4.19 156/191] powerpc: Warn about use of smt_snooze_delay
On Thu, 5 Nov 2020 at 19:24, Pavel Machek <pavel@....cz> wrote:
>
> Hi!
>
> > From: Joel Stanley <joel@....id.au>
> >
> > commit a02f6d42357acf6e5de6ffc728e6e77faf3ad217 upstream.
> >
> > It's not done anything for a long time. Save the percpu variable, and
> > emit a warning to remind users to not expect it to do anything.
> >
> > This uses pr_warn_once instead of pr_warn_ratelimit as testing
> > 'ppc64_cpu --smt=off' on a 24 core / 4 SMT system showed the warning
> > to be noisy, as the online/offline loop is slow.
>
> I don't believe this is good idea for stable. It is in 5.9-rc2, and
> likely mainline users will get userspace fixed, but that warning is
> less useful for -stable users.
The warning is about the existing behaviour of the kernel. It does let
the user know that they won't see any difference in behaviour when
tweaking the smt_snooze_delay variable, which was a real issue that
Anton hit.
I agree that the future commit that removes smt_snooze_delay from the
kernel should not be backported.
Cheers,
Joel
>
> (And besides, it does not fix any serious bug).
>
> Best regards,
> Pavel
>
> --
> http://www.livejournal.com/~pavelmachek
Powered by blists - more mailing lists