Re: [PATCH v4 0/2] Avoid spurious freezer wakeups

From: Ingo Molnar <mingo@kernel.org>
To: Elliot Berman <quic_eberman@quicinc.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Carlos Llamas <cmllamas@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Pavel Machek <pavel@ucw.cz>, Thomas Gleixner <tglx@linutronix.de>,
	kernel@quicinc.com, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Prakash Viswalingam <quic_prakashv@quicinc.com>
Subject: Re: [PATCH v4 0/2] Avoid spurious freezer wakeups
Date: Tue, 3 Oct 2023 15:01:55 +0200	[thread overview]
Message-ID: <ZRwQw7YP5MsiPoTg@gmail.com> (raw)
In-Reply-To: <a0456690-1917-4d82-877a-f23d871049b5@quicinc.com>

* Elliot Berman <quic_eberman@quicinc.com> wrote:

> Hi Peter,
> 
> On 9/26/2023 1:02 PM, Peter Zijlstra wrote:
> > On Tue, Sep 26, 2023 at 04:17:33PM +0000, Carlos Llamas wrote:
> >> On Fri, Sep 08, 2023 at 03:49:14PM -0700, Elliot Berman wrote:
> >>> After commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic"),
> >>> tasks that transition directly from TASK_FREEZABLE to TASK_FROZEN  are
> >>> always woken up on the thaw path. Prior to that commit, tasks could ask
> >>> freezer to consider them "frozen enough" via freezer_do_not_count(). The
> >>> commit replaced freezer_do_not_count() with a TASK_FREEZABLE state which
> >>> allows freezer to immediately mark the task as TASK_FROZEN without
> >>> waking up the task.  This is efficient for the suspend path, but on the
> >>> thaw path, the task is always woken up even if the task didn't need to
> >>> wake up and goes back to its TASK_(UN)INTERRUPTIBLE state. Although
> >>> these tasks are capable of handling of the wakeup, we can observe a
> >>> power/perf impact from the extra wakeup.
> >>
> >> This issue is hurting the performance of our stable 6.1 releases. Does
> >> it make sense to backport these patches into stable branches once they
> >> land in mainline? I would assume we want to fix the perf regression
> >> there too?
> > 
> > Note that these patches are in tip/sched/core, slated for the next merge
> > window.
> 
> Can the changes be scheduled for the next 6.6-rc? I'd like to get the
> changes backported to stable sooner since we observed the regression on
> real systems.

These are pretty risky and go beyond fixes for regressions introduced
recently: the original commit is more than a year old.

But I agree with having the fixes in stable once it hits upstream in the v6.7 
merge window - the difference would only be a couple of days vs. -final.

Thanks,

	Ingo