From: Carlos Llamas <cmllamas@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Elliot Berman <quic_eberman@quicinc.com>,
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>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v4 0/2] Avoid spurious freezer wakeups
Date: Tue, 26 Sep 2023 20:56:25 +0000 [thread overview]
Message-ID: <ZRNFeXZ4tRbT7ws6@google.com> (raw)
In-Reply-To: <20230926200238.GB13828@noisy.programming.kicks-ass.net>
On Tue, Sep 26, 2023 at 10:02:38PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 26, 2023 at 04:17:33PM +0000, Carlos Llamas wrote:
> >
> > 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.
We can wait, no problem. I just wanted to make sure we also patch stable
if needed. Elliot, would you be able to send a backport of your patches
to stable once they land in mainline on the next merge window?
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
--
Carlos Llamas
next prev parent reply other threads:[~2023-09-26 22:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 22:49 [PATCH v4 0/2] Avoid spurious freezer wakeups Elliot Berman
2023-09-08 22:49 ` [PATCH v4 1/2] sched/core: Remove ifdeffery for saved_state Elliot Berman
2023-09-08 22:49 ` [PATCH v4 2/2] freezer,sched: Use saved_state to reduce some spurious wakeups Elliot Berman
2023-09-11 15:49 ` [PATCH v4 0/2] Avoid spurious freezer wakeups Peter Zijlstra
2023-09-26 16:17 ` Carlos Llamas
2023-09-26 20:02 ` Peter Zijlstra
2023-09-26 20:56 ` Carlos Llamas [this message]
2023-09-26 22:04 ` Elliot Berman
2023-09-28 16:24 ` Elliot Berman
2023-10-03 13:01 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZRNFeXZ4tRbT7ws6@google.com \
--to=cmllamas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@quicinc.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=quic_eberman@quicinc.com \
--cc=quic_prakashv@quicinc.com \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.