[RFC} Commit 8a99b6833c88 Moves Important Real-time Settings To DebugFS

[RFC} Commit 8a99b6833c88 Moves Important Real-time Settings To DebugFS

[Joseph Salisbury]

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

Re: [RFC} Commit 8a99b6833c88 Moves Important Real-time Settings To DebugFS

[Peter Zijlstra]

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 ?

Re: [RFC} Commit 8a99b6833c88 Moves Important Real-time Settings To DebugFS

[Joseph Salisbury]

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/

Re: [RFC} Commit 8a99b6833c88 Moves Important Real-time Settings To DebugFS

[Joseph Salisbury]

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