linux-kernel - Re: [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO

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] [day] [month] [year] [list]

Message-ID: <cb7be27b-8063-4eba-98b7-3672c8c41b96@amazon.com>
Date: Fri, 18 Oct 2024 10:54:19 +0100
From: "Mohamed Abuelfotoh, Hazem" <abuehaze@...zon.com>
To: "Prundeanu, Cristian" <cpru@...zon.com>, Peter Zijlstra
	<peterz@...radead.org>
CC: "linux-tip-commits@...r.kernel.org" <linux-tip-commits@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Ingo Molnar
	<mingo@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "Doebel, Bjoern" <doebel@...zon.de>,
	"Blake, Geoff" <blakgeof@...zon.com>, "Saidi, Ali" <alisaidi@...zon.com>,
	"Csoma, Csaba" <csabac@...zon.com>, "gautham.shenoy@....com"
	<gautham.shenoy@....com>
Subject: Re: [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY
 and move them to sysctl

>> And sysctl is arguably more of an ABI than debugfs, which
>> doesn't really sound suitable for workaround.
>>
>> And I don't see how adding a line to /etc/rc.local is harder than adding
>> a line to /etc/sysctl.conf
> 
> Adding a line is equally difficult both ways, you're right. But aren't
> most distros better equipped to manage (persist, modify, automate) sysctl
> parameters in a standardized manner?
> Whereas rc.local seems more "individual need / edge case" oriented. For
> instance: changes are done by editing the file, which is poorly scriptable
> (unlike the sysctl command, which is a unified interface that reconciles
> changes); the load order is also typically late in the boot stage, making
> it not an ideal place for settings that affect system processes.
> 

I'd add to what Cristian mentioned is that having these tunables as 
sysctls will make them more detectable to the end users because checking 
output of sysctl -a is usually one of the first steps during performance 
troubleshooting vs checking /sys/kernel/debug/sched/ files so it's 
easier for people to spot these configurations as sysctls if they notice 
performance difference after upgrading the kernel.

Hazem