Re: [PATCH v3 4/4] arm: defconfig: drop RT_GROUP_SCHED=y from bcm2835/tegra/omap2plus

Thierry Reding <[email protected]> Thu, 24 Oct 2024 19:10:23 +0200

Newsgroups	gmane.linux.ports.tegra,gmane.linux.ports.riscv,gmane.linux.kernel,gmane.linux.ports.sh.devel,gmane.linux.ports.arm.kernel,gmane.linux.kernel.rpi,gmane.linux.ports.arm.omap
Message-ID	<6m77wg6b76abyk2ebfniayxvrabvzur7onwar4isajb6tvfxbv@7a24p2xkmevj>

On Tue, Sep 10, 2024 at 08:51:10PM +0800, Celeste Liu wrote:
> Commit 673ce00c5d6c ("ARM: omap2plus_defconfig: Add support for distros
> with systemd") said it's because of recommendation from systemd. But
> systemd changed their recommendation later.[1]
> 
> For cgroup v1, if turned on, and there's any cgroup in the "cpu" hierarchy it
> needs an RT budget assigned, otherwise the processes in it will not be able to
> get RT at all. The problem with RT group scheduling is that it requires the
> budget assigned but there's no way we could assign a default budget, since the
> values to assign are both upper and lower time limits, are absolute, and need to
> be sum up to < 1 for each individal cgroup. That means we cannot really come up
> with values that would work by default in the general case.[2]
> 
> For cgroup v2, it's almost unusable as well. If it turned on, the cpu controller
> can only be enabled when all RT processes are in the root cgroup. But it will
> lose the benefits of cgroup v2 if all RT process were placed in the same cgroup.
> 
> Red Hat, Gentoo, Arch Linux and Debian all disable it. systemd also doesn't
> support it.
> 
> [1]: https://github.com/systemd/systemd/commit/f4e74be1856b3ac058acbf1be321c31d5299f69f
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1229700
> 
> Tested-by: Stefan Wahren <[email protected]>
> Acked-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/[email protected]>
> Signed-off-by: Celeste Liu <[email protected]>
> ---
>  arch/arm/configs/bcm2835_defconfig   | 1 -
>  arch/arm/configs/omap2plus_defconfig | 1 -
>  arch/arm/configs/tegra_defconfig     | 1 -
>  3 files changed, 3 deletions(-)

Any idea who will want to pick this up? Probably something the ARM SoC
maintainers can do directly, in which case:

Acked-by: Thierry Reding <[email protected]>

signature.asc (application/pgp-signature, 833 B)