Hello,
Some Ubuntu users are using the tuned package with a 5.15.x based
real-time kernel. Tuned adjusts various sysctl options based on a
specified profile. This userspace package has stopped working > 5.13
due to the following commit:
8a99b6833c88 "(sched: Move SCHED_DEBUG sysctl to debugfs)"
This commit moved some important real-time sysctl knobs to debugfs in
5.13-rc1. It also appears some of the sysctl options were not moved,
sched_min_granularity_ns, for example.
I was hoping to get some feedback on how to approach this. Would
upstream real-time consider accepting a patch to the 5.15 real-time
patch set that reverts this commit? Or a new patch that adds the sysctl
settings back? Any other ideas or feedback would be appreciated!
Thanks in advance,
Joe
On Thu, Aug 18, 2022 at 03:53:28PM -0400, Joseph Salisbury wrote:
> Hello,
>
> Some Ubuntu users are using the tuned package with a 5.15.x based real-time
> kernel.? Tuned adjusts various sysctl options based on a specified profile.?
> This userspace package has stopped working > 5.13 due to the following
> commit:
>
> 8a99b6833c88 "(sched: Move SCHED_DEBUG sysctl to debugfs)"
>
> This commit moved some important real-time sysctl knobs to debugfs in
> 5.13-rc1.? It also appears some of the sysctl options were not moved,
> sched_min_granularity_ns, for example.
>
> I was hoping to get some feedback on how to approach this.? Would upstream
> real-time consider accepting a patch to the 5.15 real-time patch set that
> reverts this commit?? Or a new patch that adds the sysctl settings back??
> Any other ideas or feedback would be appreciated!
None of those knobs were available when SCHED_DEBUG=n, so relying on
them is your error to begin with.
Secondly, real-time? Which if those values affects anything in
SCHED_FIFO/RR/DEADLINE ?
On 8/18/22 16:31, Peter Zijlstra wrote:
> On Thu, Aug 18, 2022 at 03:53:28PM -0400, Joseph Salisbury wrote:
>> Hello,
>>
>> Some Ubuntu users are using the tuned package with a 5.15.x based real-time
>> kernel. Tuned adjusts various sysctl options based on a specified profile.
>> This userspace package has stopped working > 5.13 due to the following
>> commit:
>>
>> 8a99b6833c88 "(sched: Move SCHED_DEBUG sysctl to debugfs)"
>>
>> This commit moved some important real-time sysctl knobs to debugfs in
>> 5.13-rc1. It also appears some of the sysctl options were not moved,
>> sched_min_granularity_ns, for example.
>>
>> I was hoping to get some feedback on how to approach this. Would upstream
>> real-time consider accepting a patch to the 5.15 real-time patch set that
>> reverts this commit? Or a new patch that adds the sysctl settings back?
>> Any other ideas or feedback would be appreciated!
> None of those knobs were available when SCHED_DEBUG=n, so relying on
> them is your error to begin with.
We have had SCHED_DEBUG=y while this kernel is in beta, so you are
correct. I need to investigate a different approach.
>
> Secondly, real-time? Which if those values affects anything in
> SCHED_FIFO/RR/DEADLINE ?
I am in the process of understanding how tuned[0] works. Many users have
reported success using tuned. One use case for tuned is to assign
isolated cores to real-time processes and then move managed IRQs out of
these isolated cores. This can be done easily with tuned (I will
research if there are other options to suggest). However, tuned is
trying to set the affected values when enabling a profile, such as the
real-time profile (Tuned offers many profiles based on a workload type).
I will investigate further to answer your point of what in
SCHED_FIFO/RR/DEADLINE those values affect. It could be those values
are not needed at all. The dependency on them might be left over from
some need that no longer exists.
Thank you again for the feedback!
[0] https://tuned-project.org/
On 8/18/22 21:38, Joseph Salisbury wrote:
>
>
> On 8/18/22 16:31, Peter Zijlstra wrote:
>> On Thu, Aug 18, 2022 at 03:53:28PM -0400, Joseph Salisbury wrote:
>>> Hello,
>>>
>>> Some Ubuntu users are using the tuned package with a 5.15.x based
>>> real-time
>>> kernel. Tuned adjusts various sysctl options based on a specified
>>> profile.
>>> This userspace package has stopped working > 5.13 due to the following
>>> commit:
>>>
>>> 8a99b6833c88 "(sched: Move SCHED_DEBUG sysctl to debugfs)"
>>>
>>> This commit moved some important real-time sysctl knobs to debugfs in
>>> 5.13-rc1. It also appears some of the sysctl options were not moved,
>>> sched_min_granularity_ns, for example.
>>>
>>> I was hoping to get some feedback on how to approach this. Would
>>> upstream
>>> real-time consider accepting a patch to the 5.15 real-time patch set
>>> that
>>> reverts this commit? Or a new patch that adds the sysctl settings
>>> back?
>>> Any other ideas or feedback would be appreciated!
>> None of those knobs were available when SCHED_DEBUG=n, so relying on
>> them is your error to begin with.
> We have had SCHED_DEBUG=y while this kernel is in beta, so you are
> correct. I need to investigate a different approach.
>>
>> Secondly, real-time? Which if those values affects anything in
>> SCHED_FIFO/RR/DEADLINE ?
> I am in the process of understanding how tuned[0] works. Many users
> have reported success using tuned. One use case for tuned is to
> assign isolated cores to real-time processes and then move managed
> IRQs out of these isolated cores. This can be done easily with tuned
> (I will research if there are other options to suggest). However,
> tuned is trying to set the affected values when enabling a profile,
> such as the real-time profile (Tuned offers many profiles based on a
> workload type).
>
> I will investigate further to answer your point of what in
> SCHED_FIFO/RR/DEADLINE those values affect. It could be those values
> are not needed at all. The dependency on them might be left over from
> some need that no longer exists.
>
> Thank you again for the feedback!
>
> [0] https://tuned-project.org/
>
I also see that the github repo[0] is at version 2.19-rc1, and the
version being testing is 2.15. Many of the issues we see may already be
resolved.
I will find out how I can participate in the tuned community. At a
minimum, I can start with testing and bug fixes.
Thanks again for your feedback, Peter. And sorry for the noise.
Thanks,
Joe
[0] https://github.com/redhat-performance/tuned