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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b107a46a-7f53-0b35-71f4-9a909643c4c1@canonical.com>
Date:   Thu, 18 Aug 2022 21:38:46 -0400
From:   Joseph Salisbury <joseph.salisbury@...onical.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-rt-users@...r.kernel.org, williams@...hat.com,
        bigeasy@...utronix.de, valentin.schneider@....com,
        linux-kernel@...r.kernel.org,
        Marcelo Cerri <marcelo.cerri@...onical.com>
Subject: Re: [RFC} Commit 8a99b6833c88 Moves Important Real-time Settings To
 DebugFS



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/