Hello,
The following patches prevent Linux 6.6.78+ rtla to build:
- "rtla/timerlat_top: Set OSNOISE_WORKLOAD for kernel threads" (stable commit 41955b6c268154f81e34f9b61cf8156eec0730c0) - "rtla/timerlat_hist: Set OSNOISE_WORKLOAD for kernel threads" (stable commit 83b74901bdc9b58739193b8ee6989254391b6ba7)
Both were added to Linux 6.6.78 based on the Fixes tag in the upstream commits.
These patches prevent 6.6.78 rta to build with a similar error (missing kernel_workload in the params struct) src/timerlat_top.c:687:52: error: ‘struct timerlat_top_params’ has no member named ‘kernel_workload’
These patches appear to depend on "rtla/timerlat: Make user-space threads the default" commit fb9e90a67ee9a42779a8ea296a4cf7734258b27d which is not present in 6.6.
I am not sure if it's better to revert them or pick up fb9e90a67ee9a42779a8ea296a4cf7734258b27d in 6.6. Tomas, what do you think?
HTH,
Guillaume.
Hello,
st 19. 2. 2025 v 15:48 odesílatel Guillaume Morin guillaume@morinfr.org napsal:
Hello,
The following patches prevent Linux 6.6.78+ rtla to build:
- "rtla/timerlat_top: Set OSNOISE_WORKLOAD for kernel threads" (stable
commit 41955b6c268154f81e34f9b61cf8156eec0730c0)
- "rtla/timerlat_hist: Set OSNOISE_WORKLOAD for kernel threads" (stable
commit 83b74901bdc9b58739193b8ee6989254391b6ba7)
Both were added to Linux 6.6.78 based on the Fixes tag in the upstream commits.
These patches prevent 6.6.78 rta to build with a similar error (missing kernel_workload in the params struct) src/timerlat_top.c:687:52: error: ‘struct timerlat_top_params’ has no member named ‘kernel_workload’
I did not realize that, sorry!
These patches appear to depend on "rtla/timerlat: Make user-space threads the default" commit fb9e90a67ee9a42779a8ea296a4cf7734258b27d which is not present in 6.6.
I am not sure if it's better to revert them or pick up fb9e90a67ee9a42779a8ea296a4cf7734258b27d in 6.6. Tomas, what do you think?
We don't want to pick up fb9e90a67ee9a42779a8ea296a4cf7734258b27d (rtla/timerlat: Make user-space threads the default) to stable, since it changes the default behavior as well as output of rtla.
The patches can be fixed by by substituting params->kernel_workload for !params->user_hist (!params->user_top) for the version of the files that is present in 6.6-stable (6.1-stable is not affected, since it doesn't have user workload mode at all).
I'm not sure what the correct procedure would be. One way I can think of is reverting the patch as broken, and me sending an alternate version of the patch for 6.6-stable containing the change above. That would be the cleanest way in my opinion (as compared to sending the fixup directly).
Tomas
On 19 Feb 16:03, Tomas Glozar wrote:
Hello,
st 19. 2. 2025 v 15:48 odesílatel Guillaume Morin guillaume@morinfr.org napsal:
Hello,
The following patches prevent Linux 6.6.78+ rtla to build:
- "rtla/timerlat_top: Set OSNOISE_WORKLOAD for kernel threads" (stable
commit 41955b6c268154f81e34f9b61cf8156eec0730c0)
- "rtla/timerlat_hist: Set OSNOISE_WORKLOAD for kernel threads" (stable
commit 83b74901bdc9b58739193b8ee6989254391b6ba7)
Both were added to Linux 6.6.78 based on the Fixes tag in the upstream commits.
These patches prevent 6.6.78 rta to build with a similar error (missing kernel_workload in the params struct) src/timerlat_top.c:687:52: error: ‘struct timerlat_top_params’ has no member named ‘kernel_workload’
I did not realize that, sorry!
These patches appear to depend on "rtla/timerlat: Make user-space threads the default" commit fb9e90a67ee9a42779a8ea296a4cf7734258b27d which is not present in 6.6.
I am not sure if it's better to revert them or pick up fb9e90a67ee9a42779a8ea296a4cf7734258b27d in 6.6. Tomas, what do you think?
We don't want to pick up fb9e90a67ee9a42779a8ea296a4cf7734258b27d (rtla/timerlat: Make user-space threads the default) to stable, since it changes the default behavior as well as output of rtla.
The patches can be fixed by by substituting params->kernel_workload for !params->user_hist (!params->user_top) for the version of the files that is present in 6.6-stable (6.1-stable is not affected, since it doesn't have user workload mode at all).
I'm not sure what the correct procedure would be. One way I can think of is reverting the patch as broken, and me sending an alternate version of the patch for 6.6-stable containing the change above. That would be the cleanest way in my opinion (as compared to sending the fixup directly).
Either way would work for me. Not sure what Greg prefers however
On Thu, Feb 20, 2025 at 03:03:29PM +0100, Guillaume Morin wrote:
On 19 Feb 16:03, Tomas Glozar wrote:
Hello,
st 19. 2. 2025 v 15:48 odesílatel Guillaume Morin guillaume@morinfr.org napsal:
Hello,
The following patches prevent Linux 6.6.78+ rtla to build:
- "rtla/timerlat_top: Set OSNOISE_WORKLOAD for kernel threads" (stable
commit 41955b6c268154f81e34f9b61cf8156eec0730c0)
- "rtla/timerlat_hist: Set OSNOISE_WORKLOAD for kernel threads" (stable
commit 83b74901bdc9b58739193b8ee6989254391b6ba7)
Both were added to Linux 6.6.78 based on the Fixes tag in the upstream commits.
These patches prevent 6.6.78 rta to build with a similar error (missing kernel_workload in the params struct) src/timerlat_top.c:687:52: error: ‘struct timerlat_top_params’ has no member named ‘kernel_workload’
I did not realize that, sorry!
These patches appear to depend on "rtla/timerlat: Make user-space threads the default" commit fb9e90a67ee9a42779a8ea296a4cf7734258b27d which is not present in 6.6.
I am not sure if it's better to revert them or pick up fb9e90a67ee9a42779a8ea296a4cf7734258b27d in 6.6. Tomas, what do you think?
We don't want to pick up fb9e90a67ee9a42779a8ea296a4cf7734258b27d (rtla/timerlat: Make user-space threads the default) to stable, since it changes the default behavior as well as output of rtla.
The patches can be fixed by by substituting params->kernel_workload for !params->user_hist (!params->user_top) for the version of the files that is present in 6.6-stable (6.1-stable is not affected, since it doesn't have user workload mode at all).
I'm not sure what the correct procedure would be. One way I can think of is reverting the patch as broken, and me sending an alternate version of the patch for 6.6-stable containing the change above. That would be the cleanest way in my opinion (as compared to sending the fixup directly).
Either way would work for me. Not sure what Greg prefers however
I prefer to take whatever is upstream, and if that doesn't work, and these were applied incorrectly, we can just revert them.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Guillaume Morin -
Tomas Glozar