On 2025.11.13 07:22 Christian Loehle wrote: > On 11/12/25 16:21, Rafael J. Wysocki wrote: >> Hi, >> >> This is a bunch of teo cpuidle governor improvements, some of which are related >> to a bug report discussed recently: >> >> https://lore.kernel.org/linux-pm/CAEmPcwsNMNnNXuxgvHTQ93Mx-q3Oz9U57THQsU_qdcCx1m4w5g@mail.gmail.com/ >> >> The first patch fixes a bug that may cause an overly deep idle state >> to be selected when the scheduler tick has been already stopped. >> >> Patch [2/4] removes an unnecessary function argument. >> >> Patch [3/4] makes teo_update() to use s64 as the data type for its local >> variables more consistently. >> >> The last patch reworks the governor's decay implementation to also decay >> metric values lower than 8. >> > > Tested-by: Christian Loehle <christian.loehle@arm.com> > > Test results below, although there really isn't anything interesting in there. > teo-1 to teo-4 (patches 1 to 4 respectively are essentially indistinguishable from > teo-m = mainline) I tested the 4 patch set also, and also found no differences in results above repeatability noise levels. Additionally, I added another patch (patch 5 of 4): "cpuidle: governors: teo: Rework the handling of tick wakeups" [1] Similar findings. Additionally, I added another patch (patch 6 of 4): "sched/idle: disable tick in idle=poll idle entry" [2] And found only one significant improvement, for only one test, but only for the TEO idle governor: Kernel 6.18-rc4: For a 6 pair fast ping-pong test (meaning no work per token stop): teo: 5.53 uSec per loop, reference test 4 of 4 patches: 5.53 uSec per loop, 0% 5 of 4 patches: 5.54 uSec per loop, 0.2% (noise) 6 of 4 patches: 4.77 uSec per loop, 13% better 6 of 4 patches (again): 4.81 uSec per loop, 13% better menu: 5.29 uSec per loop, 4.4% better menu + patch 6 of 4: 5.28 uSec per loop, 4.5% better Idle state 0 usage: 18% with patch 6, teo 11% with menu ~1% with mainline and not patch 6, teo. Idle state 1 usage: almost 0 with patch 6, teo ~6% with menu 27% with mainline and not patch 6, teo. Power: About 100 watts. Patch 6 and teo does increase power use by about a watt or 2. Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs. For clarity my branch log: 3993913d7f81 (HEAD -> rjw-teo) sched/idle: disable tick in idle=poll idle entry d9b12b8d62bf cpuidle: governors: teo: Rework the handling of tick wakeups e47178c87272 cpuidle: governors: teo: Decay metrics below DECAY_SHIFT threshold 7fe32e411c2b cpuidle: governors: teo: Use s64 consistently in teo_update() 490e6118e45d cpuidle: governors: teo: Drop redundant function parameter 8f627f86062e cpuidle: governors: teo: Drop incorrect target residency check 6146a0f1dfae (tag: v6.18-rc4, origin/master, origin/HEAD, master) Linux 6.18-rc4 [1] https://lore.kernel.org/linux-pm/6228387.lOV4Wx5bFT@rafael.j.wysocki/ [2] https://lore.kernel.org/linux-pm/aQiWfnnSzxsnwa2o@tpad/
On Wed, Nov 19, 2025 at 11:52 PM Doug Smythies <dsmythies@telus.net> wrote: > > On 2025.11.13 07:22 Christian Loehle wrote: > > On 11/12/25 16:21, Rafael J. Wysocki wrote: > >> Hi, > >> > >> This is a bunch of teo cpuidle governor improvements, some of which are related > >> to a bug report discussed recently: > >> > >> https://lore.kernel.org/linux-pm/CAEmPcwsNMNnNXuxgvHTQ93Mx-q3Oz9U57THQsU_qdcCx1m4w5g@mail.gmail.com/ > >> > >> The first patch fixes a bug that may cause an overly deep idle state > >> to be selected when the scheduler tick has been already stopped. > >> > >> Patch [2/4] removes an unnecessary function argument. > >> > >> Patch [3/4] makes teo_update() to use s64 as the data type for its local > >> variables more consistently. > >> > >> The last patch reworks the governor's decay implementation to also decay > >> metric values lower than 8. > >> > > > > Tested-by: Christian Loehle <christian.loehle@arm.com> > > > > Test results below, although there really isn't anything interesting in there. > > teo-1 to teo-4 (patches 1 to 4 respectively are essentially indistinguishable from > > teo-m = mainline) > > I tested the 4 patch set also, and also found no differences in results above > repeatability noise levels. > > Additionally, I added another patch (patch 5 of 4): > "cpuidle: governors: teo: Rework the handling of tick wakeups" [1] > Similar findings. > > Additionally, I added another patch (patch 6 of 4): > "sched/idle: disable tick in idle=poll idle entry" [2] > And found only one significant improvement, for only one test, > but only for the TEO idle governor: > > Kernel 6.18-rc4: > For a 6 pair fast ping-pong test (meaning no work per token stop): > teo: 5.53 uSec per loop, reference test > 4 of 4 patches: 5.53 uSec per loop, 0% > 5 of 4 patches: 5.54 uSec per loop, 0.2% (noise) > 6 of 4 patches: 4.77 uSec per loop, 13% better > 6 of 4 patches (again): 4.81 uSec per loop, 13% better > menu: 5.29 uSec per loop, 4.4% better > menu + patch 6 of 4: 5.28 uSec per loop, 4.5% better > > Idle state 0 usage: > 18% with patch 6, teo > 11% with menu > ~1% with mainline and not patch 6, teo. > > Idle state 1 usage: > almost 0 with patch 6, teo > ~6% with menu > 27% with mainline and not patch 6, teo. > > Power: About 100 watts. Patch 6 and teo does increase power use by about a watt or 2. > > Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs. > > For clarity my branch log: > 3993913d7f81 (HEAD -> rjw-teo) sched/idle: disable tick in idle=poll idle entry > d9b12b8d62bf cpuidle: governors: teo: Rework the handling of tick wakeups > e47178c87272 cpuidle: governors: teo: Decay metrics below DECAY_SHIFT threshold > 7fe32e411c2b cpuidle: governors: teo: Use s64 consistently in teo_update() > 490e6118e45d cpuidle: governors: teo: Drop redundant function parameter > 8f627f86062e cpuidle: governors: teo: Drop incorrect target residency check > 6146a0f1dfae (tag: v6.18-rc4, origin/master, origin/HEAD, master) Linux 6.18-rc4 > > [1] https://lore.kernel.org/linux-pm/6228387.lOV4Wx5bFT@rafael.j.wysocki/ > [2] https://lore.kernel.org/linux-pm/aQiWfnnSzxsnwa2o@tpad/ Thanks for the feedback, much appreciated! I will likely have some more teo updates in the next cycle.
On 11/20/25 11:02, Rafael J. Wysocki wrote: > On Wed, Nov 19, 2025 at 11:52 PM Doug Smythies <dsmythies@telus.net> wrote: >> >> On 2025.11.13 07:22 Christian Loehle wrote: >>> On 11/12/25 16:21, Rafael J. Wysocki wrote: >>>> Hi, >>>> >>>> This is a bunch of teo cpuidle governor improvements, some of which are related >>>> to a bug report discussed recently: >>>> >>>> https://lore.kernel.org/linux-pm/CAEmPcwsNMNnNXuxgvHTQ93Mx-q3Oz9U57THQsU_qdcCx1m4w5g@mail.gmail.com/ >>>> >>>> The first patch fixes a bug that may cause an overly deep idle state >>>> to be selected when the scheduler tick has been already stopped. >>>> >>>> Patch [2/4] removes an unnecessary function argument. >>>> >>>> Patch [3/4] makes teo_update() to use s64 as the data type for its local >>>> variables more consistently. >>>> >>>> The last patch reworks the governor's decay implementation to also decay >>>> metric values lower than 8. >>>> >>> >>> Tested-by: Christian Loehle <christian.loehle@arm.com> >>> >>> Test results below, although there really isn't anything interesting in there. >>> teo-1 to teo-4 (patches 1 to 4 respectively are essentially indistinguishable from >>> teo-m = mainline) >> >> I tested the 4 patch set also, and also found no differences in results above >> repeatability noise levels. >> >> Additionally, I added another patch (patch 5 of 4): >> "cpuidle: governors: teo: Rework the handling of tick wakeups" [1] >> Similar findings. >> >> Additionally, I added another patch (patch 6 of 4): >> "sched/idle: disable tick in idle=poll idle entry" [2] >> And found only one significant improvement, for only one test, >> but only for the TEO idle governor: >> >> Kernel 6.18-rc4: >> For a 6 pair fast ping-pong test (meaning no work per token stop): >> teo: 5.53 uSec per loop, reference test >> 4 of 4 patches: 5.53 uSec per loop, 0% >> 5 of 4 patches: 5.54 uSec per loop, 0.2% (noise) >> 6 of 4 patches: 4.77 uSec per loop, 13% better >> 6 of 4 patches (again): 4.81 uSec per loop, 13% better >> menu: 5.29 uSec per loop, 4.4% better >> menu + patch 6 of 4: 5.28 uSec per loop, 4.5% better >> >> Idle state 0 usage: >> 18% with patch 6, teo >> 11% with menu >> ~1% with mainline and not patch 6, teo. >> >> Idle state 1 usage: >> almost 0 with patch 6, teo >> ~6% with menu >> 27% with mainline and not patch 6, teo. >> >> Power: About 100 watts. Patch 6 and teo does increase power use by about a watt or 2. >> >> Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs. >> >> For clarity my branch log: >> 3993913d7f81 (HEAD -> rjw-teo) sched/idle: disable tick in idle=poll idle entry >> d9b12b8d62bf cpuidle: governors: teo: Rework the handling of tick wakeups >> e47178c87272 cpuidle: governors: teo: Decay metrics below DECAY_SHIFT threshold >> 7fe32e411c2b cpuidle: governors: teo: Use s64 consistently in teo_update() >> 490e6118e45d cpuidle: governors: teo: Drop redundant function parameter >> 8f627f86062e cpuidle: governors: teo: Drop incorrect target residency check >> 6146a0f1dfae (tag: v6.18-rc4, origin/master, origin/HEAD, master) Linux 6.18-rc4 >> >> [1] https://lore.kernel.org/linux-pm/6228387.lOV4Wx5bFT@rafael.j.wysocki/ >> [2] https://lore.kernel.org/linux-pm/aQiWfnnSzxsnwa2o@tpad/ > > Thanks for the feedback, much appreciated! > > I will likely have some more teo updates in the next cycle. You're welcome, looking forward to reviewing them too. I haven't tried to see what this would ideally look like for the -stable branches. Just backport everything until the most recent applicable Fixes:?
On Thu, Nov 20, 2025 at 2:35 PM Christian Loehle <christian.loehle@arm.com> wrote: > > On 11/20/25 11:02, Rafael J. Wysocki wrote: > > On Wed, Nov 19, 2025 at 11:52 PM Doug Smythies <dsmythies@telus.net> wrote: > >> > >> On 2025.11.13 07:22 Christian Loehle wrote: > >>> On 11/12/25 16:21, Rafael J. Wysocki wrote: > >>>> Hi, > >>>> > >>>> This is a bunch of teo cpuidle governor improvements, some of which are related > >>>> to a bug report discussed recently: > >>>> > >>>> https://lore.kernel.org/linux-pm/CAEmPcwsNMNnNXuxgvHTQ93Mx-q3Oz9U57THQsU_qdcCx1m4w5g@mail.gmail.com/ > >>>> > >>>> The first patch fixes a bug that may cause an overly deep idle state > >>>> to be selected when the scheduler tick has been already stopped. > >>>> > >>>> Patch [2/4] removes an unnecessary function argument. > >>>> > >>>> Patch [3/4] makes teo_update() to use s64 as the data type for its local > >>>> variables more consistently. > >>>> > >>>> The last patch reworks the governor's decay implementation to also decay > >>>> metric values lower than 8. > >>>> > >>> > >>> Tested-by: Christian Loehle <christian.loehle@arm.com> > >>> > >>> Test results below, although there really isn't anything interesting in there. > >>> teo-1 to teo-4 (patches 1 to 4 respectively are essentially indistinguishable from > >>> teo-m = mainline) > >> > >> I tested the 4 patch set also, and also found no differences in results above > >> repeatability noise levels. > >> > >> Additionally, I added another patch (patch 5 of 4): > >> "cpuidle: governors: teo: Rework the handling of tick wakeups" [1] > >> Similar findings. > >> > >> Additionally, I added another patch (patch 6 of 4): > >> "sched/idle: disable tick in idle=poll idle entry" [2] > >> And found only one significant improvement, for only one test, > >> but only for the TEO idle governor: > >> > >> Kernel 6.18-rc4: > >> For a 6 pair fast ping-pong test (meaning no work per token stop): > >> teo: 5.53 uSec per loop, reference test > >> 4 of 4 patches: 5.53 uSec per loop, 0% > >> 5 of 4 patches: 5.54 uSec per loop, 0.2% (noise) > >> 6 of 4 patches: 4.77 uSec per loop, 13% better > >> 6 of 4 patches (again): 4.81 uSec per loop, 13% better > >> menu: 5.29 uSec per loop, 4.4% better > >> menu + patch 6 of 4: 5.28 uSec per loop, 4.5% better > >> > >> Idle state 0 usage: > >> 18% with patch 6, teo > >> 11% with menu > >> ~1% with mainline and not patch 6, teo. > >> > >> Idle state 1 usage: > >> almost 0 with patch 6, teo > >> ~6% with menu > >> 27% with mainline and not patch 6, teo. > >> > >> Power: About 100 watts. Patch 6 and teo does increase power use by about a watt or 2. > >> > >> Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs. > >> > >> For clarity my branch log: > >> 3993913d7f81 (HEAD -> rjw-teo) sched/idle: disable tick in idle=poll idle entry > >> d9b12b8d62bf cpuidle: governors: teo: Rework the handling of tick wakeups > >> e47178c87272 cpuidle: governors: teo: Decay metrics below DECAY_SHIFT threshold > >> 7fe32e411c2b cpuidle: governors: teo: Use s64 consistently in teo_update() > >> 490e6118e45d cpuidle: governors: teo: Drop redundant function parameter > >> 8f627f86062e cpuidle: governors: teo: Drop incorrect target residency check > >> 6146a0f1dfae (tag: v6.18-rc4, origin/master, origin/HEAD, master) Linux 6.18-rc4 > >> > >> [1] https://lore.kernel.org/linux-pm/6228387.lOV4Wx5bFT@rafael.j.wysocki/ > >> [2] https://lore.kernel.org/linux-pm/aQiWfnnSzxsnwa2o@tpad/ > > > > Thanks for the feedback, much appreciated! > > > > I will likely have some more teo updates in the next cycle. > > You're welcome, looking forward to reviewing them too. > I haven't tried to see what this would ideally look like for the -stable branches. > Just backport everything until the most recent applicable Fixes:? I've added a list to this commit: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=14c66155c4609f1a1207d4e716c5e722b8bf920e
On Thu, Nov 20, 2025 at 2:38 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Thu, Nov 20, 2025 at 2:35 PM Christian Loehle > <christian.loehle@arm.com> wrote: > > > > On 11/20/25 11:02, Rafael J. Wysocki wrote: > > > On Wed, Nov 19, 2025 at 11:52 PM Doug Smythies <dsmythies@telus.net> wrote: > > >> > > >> On 2025.11.13 07:22 Christian Loehle wrote: > > >>> On 11/12/25 16:21, Rafael J. Wysocki wrote: > > >>>> Hi, > > >>>> > > >>>> This is a bunch of teo cpuidle governor improvements, some of which are related > > >>>> to a bug report discussed recently: > > >>>> > > >>>> https://lore.kernel.org/linux-pm/CAEmPcwsNMNnNXuxgvHTQ93Mx-q3Oz9U57THQsU_qdcCx1m4w5g@mail.gmail.com/ > > >>>> > > >>>> The first patch fixes a bug that may cause an overly deep idle state > > >>>> to be selected when the scheduler tick has been already stopped. > > >>>> > > >>>> Patch [2/4] removes an unnecessary function argument. > > >>>> > > >>>> Patch [3/4] makes teo_update() to use s64 as the data type for its local > > >>>> variables more consistently. > > >>>> > > >>>> The last patch reworks the governor's decay implementation to also decay > > >>>> metric values lower than 8. > > >>>> > > >>> > > >>> Tested-by: Christian Loehle <christian.loehle@arm.com> > > >>> > > >>> Test results below, although there really isn't anything interesting in there. > > >>> teo-1 to teo-4 (patches 1 to 4 respectively are essentially indistinguishable from > > >>> teo-m = mainline) > > >> > > >> I tested the 4 patch set also, and also found no differences in results above > > >> repeatability noise levels. > > >> > > >> Additionally, I added another patch (patch 5 of 4): > > >> "cpuidle: governors: teo: Rework the handling of tick wakeups" [1] > > >> Similar findings. > > >> > > >> Additionally, I added another patch (patch 6 of 4): > > >> "sched/idle: disable tick in idle=poll idle entry" [2] > > >> And found only one significant improvement, for only one test, > > >> but only for the TEO idle governor: > > >> > > >> Kernel 6.18-rc4: > > >> For a 6 pair fast ping-pong test (meaning no work per token stop): > > >> teo: 5.53 uSec per loop, reference test > > >> 4 of 4 patches: 5.53 uSec per loop, 0% > > >> 5 of 4 patches: 5.54 uSec per loop, 0.2% (noise) > > >> 6 of 4 patches: 4.77 uSec per loop, 13% better > > >> 6 of 4 patches (again): 4.81 uSec per loop, 13% better > > >> menu: 5.29 uSec per loop, 4.4% better > > >> menu + patch 6 of 4: 5.28 uSec per loop, 4.5% better > > >> > > >> Idle state 0 usage: > > >> 18% with patch 6, teo > > >> 11% with menu > > >> ~1% with mainline and not patch 6, teo. > > >> > > >> Idle state 1 usage: > > >> almost 0 with patch 6, teo > > >> ~6% with menu > > >> 27% with mainline and not patch 6, teo. > > >> > > >> Power: About 100 watts. Patch 6 and teo does increase power use by about a watt or 2. > > >> > > >> Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs. > > >> > > >> For clarity my branch log: > > >> 3993913d7f81 (HEAD -> rjw-teo) sched/idle: disable tick in idle=poll idle entry > > >> d9b12b8d62bf cpuidle: governors: teo: Rework the handling of tick wakeups > > >> e47178c87272 cpuidle: governors: teo: Decay metrics below DECAY_SHIFT threshold > > >> 7fe32e411c2b cpuidle: governors: teo: Use s64 consistently in teo_update() > > >> 490e6118e45d cpuidle: governors: teo: Drop redundant function parameter > > >> 8f627f86062e cpuidle: governors: teo: Drop incorrect target residency check > > >> 6146a0f1dfae (tag: v6.18-rc4, origin/master, origin/HEAD, master) Linux 6.18-rc4 > > >> > > >> [1] https://lore.kernel.org/linux-pm/6228387.lOV4Wx5bFT@rafael.j.wysocki/ > > >> [2] https://lore.kernel.org/linux-pm/aQiWfnnSzxsnwa2o@tpad/ > > > > > > Thanks for the feedback, much appreciated! > > > > > > I will likely have some more teo updates in the next cycle. > > > > You're welcome, looking forward to reviewing them too. > > I haven't tried to see what this would ideally look like for the -stable branches. > > Just backport everything until the most recent applicable Fixes:? > > I've added a list to this commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=14c66155c4609f1a1207d4e716c5e722b8bf920e Which somehow got incorrect git commit hashes, so I need to regenerate it. Sorry for the confusion.
On Thu, Nov 20, 2025 at 2:57 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Thu, Nov 20, 2025 at 2:38 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Thu, Nov 20, 2025 at 2:35 PM Christian Loehle > > <christian.loehle@arm.com> wrote: > > > > > > On 11/20/25 11:02, Rafael J. Wysocki wrote: > > > > On Wed, Nov 19, 2025 at 11:52 PM Doug Smythies <dsmythies@telus.net> wrote: > > > >> > > > >> On 2025.11.13 07:22 Christian Loehle wrote: > > > >>> On 11/12/25 16:21, Rafael J. Wysocki wrote: > > > >>>> Hi, > > > >>>> > > > >>>> This is a bunch of teo cpuidle governor improvements, some of which are related > > > >>>> to a bug report discussed recently: > > > >>>> > > > >>>> https://lore.kernel.org/linux-pm/CAEmPcwsNMNnNXuxgvHTQ93Mx-q3Oz9U57THQsU_qdcCx1m4w5g@mail.gmail.com/ > > > >>>> > > > >>>> The first patch fixes a bug that may cause an overly deep idle state > > > >>>> to be selected when the scheduler tick has been already stopped. > > > >>>> > > > >>>> Patch [2/4] removes an unnecessary function argument. > > > >>>> > > > >>>> Patch [3/4] makes teo_update() to use s64 as the data type for its local > > > >>>> variables more consistently. > > > >>>> > > > >>>> The last patch reworks the governor's decay implementation to also decay > > > >>>> metric values lower than 8. > > > >>>> > > > >>> > > > >>> Tested-by: Christian Loehle <christian.loehle@arm.com> > > > >>> > > > >>> Test results below, although there really isn't anything interesting in there. > > > >>> teo-1 to teo-4 (patches 1 to 4 respectively are essentially indistinguishable from > > > >>> teo-m = mainline) > > > >> > > > >> I tested the 4 patch set also, and also found no differences in results above > > > >> repeatability noise levels. > > > >> > > > >> Additionally, I added another patch (patch 5 of 4): > > > >> "cpuidle: governors: teo: Rework the handling of tick wakeups" [1] > > > >> Similar findings. > > > >> > > > >> Additionally, I added another patch (patch 6 of 4): > > > >> "sched/idle: disable tick in idle=poll idle entry" [2] > > > >> And found only one significant improvement, for only one test, > > > >> but only for the TEO idle governor: > > > >> > > > >> Kernel 6.18-rc4: > > > >> For a 6 pair fast ping-pong test (meaning no work per token stop): > > > >> teo: 5.53 uSec per loop, reference test > > > >> 4 of 4 patches: 5.53 uSec per loop, 0% > > > >> 5 of 4 patches: 5.54 uSec per loop, 0.2% (noise) > > > >> 6 of 4 patches: 4.77 uSec per loop, 13% better > > > >> 6 of 4 patches (again): 4.81 uSec per loop, 13% better > > > >> menu: 5.29 uSec per loop, 4.4% better > > > >> menu + patch 6 of 4: 5.28 uSec per loop, 4.5% better > > > >> > > > >> Idle state 0 usage: > > > >> 18% with patch 6, teo > > > >> 11% with menu > > > >> ~1% with mainline and not patch 6, teo. > > > >> > > > >> Idle state 1 usage: > > > >> almost 0 with patch 6, teo > > > >> ~6% with menu > > > >> 27% with mainline and not patch 6, teo. > > > >> > > > >> Power: About 100 watts. Patch 6 and teo does increase power use by about a watt or 2. > > > >> > > > >> Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs. > > > >> > > > >> For clarity my branch log: > > > >> 3993913d7f81 (HEAD -> rjw-teo) sched/idle: disable tick in idle=poll idle entry > > > >> d9b12b8d62bf cpuidle: governors: teo: Rework the handling of tick wakeups > > > >> e47178c87272 cpuidle: governors: teo: Decay metrics below DECAY_SHIFT threshold > > > >> 7fe32e411c2b cpuidle: governors: teo: Use s64 consistently in teo_update() > > > >> 490e6118e45d cpuidle: governors: teo: Drop redundant function parameter > > > >> 8f627f86062e cpuidle: governors: teo: Drop incorrect target residency check > > > >> 6146a0f1dfae (tag: v6.18-rc4, origin/master, origin/HEAD, master) Linux 6.18-rc4 > > > >> > > > >> [1] https://lore.kernel.org/linux-pm/6228387.lOV4Wx5bFT@rafael.j.wysocki/ > > > >> [2] https://lore.kernel.org/linux-pm/aQiWfnnSzxsnwa2o@tpad/ > > > > > > > > Thanks for the feedback, much appreciated! > > > > > > > > I will likely have some more teo updates in the next cycle. > > > > > > You're welcome, looking forward to reviewing them too. > > > I haven't tried to see what this would ideally look like for the -stable branches. > > > Just backport everything until the most recent applicable Fixes:? > > > > I've added a list to this commit: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=14c66155c4609f1a1207d4e716c5e722b8bf920e > > Which somehow got incorrect git commit hashes, so I need to regenerate > it. Sorry for the confusion. Done, and it's this commit now: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=083654ded547238c70e0d4f57115cd1c91245b6e
© 2016 - 2025 Red Hat, Inc.