Bug 1852890

Summary:	RFE: Add tuned hook for early tuning
Product:	Red Hat Enterprise Linux 8	Reporter:	Jiří Mencák <jmencak>
Component:	dracut	Assignee:	Lukáš Nykrýn <lnykryn>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.3	CC:	dracut-maint-list, dtardon, jskarvad, msekleta
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.3
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-01-01 07:26:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jiří Mencák 2020-07-01 14:14:43 UTC

Description of problem:
To achieve low-latencies on RHEL, early tuning during system initialization is necessary.  On RHEL, this was traditionally performed the tuned daemon and chainloading a second initramfs.  Red Hat CoreOS (RHCOS) systems, however, do not allow the addition of a second initramfs (see BZ1775917#c12).  The approach taken by RHCOS was to incorporate the tuned dracut hook[1].  To avoid further divergence between RHEL and RHCOS, I'd like to unify the early tuning so that RHCOS can drop this custom modification compared to RHEL.  This will also make tuning much simpler and more consistent between RHCOS and RHEL from containers (OCP).  See BZ1775447.

Version-Release number of selected component (if applicable):
All

Actual results:
Dracut not shipping tuned early-tuning custom hook.

Expected results:
Dracut shipping tuned early-tuning custom hook.

Additional info:
[1] https://gitlab.cee.redhat.com/coreos/redhat-coreos/-/commit/8bdc6863425ec6f95c98817e470496dcef4bf62a

Comment 2 Michal Sekletar 2020-07-18 10:14:55 UTC

I don't think it should be responsibility of the dracut maintainer to review various tuned profiles and try to cherry-pick parts (of the system config that is provided by the profile) that are relevant in initrd. IOW, tuned should provide appropriate dracut configuration dynamically whenever the profile is activated and make sure that either overlay initrd with the config is generated or main initrd is regenerated if the first option is not feasible. Jardo, any comments on this?

Comment 3 Jaroslav Škarvada 2020-07-21 14:01:38 UTC

(In reply to Michal Sekletar from comment #2)
> I don't think it should be responsibility of the dracut maintainer to review
> various tuned profiles and try to cherry-pick parts (of the system config
> that is provided by the profile) that are relevant in initrd. IOW, tuned
> should provide appropriate dracut configuration dynamically whenever the
> profile is activated and make sure that either overlay initrd with the
> config is generated or main initrd is regenerated if the first option is not
> feasible. Jardo, any comments on this?

IMHO it currently only sets the /sys/devices/virtual/workqueue/cpumask early in the boot. Systemd supports CPUAffinity settings, so could systemd set it? If yes this initrd workaround will be not needed. I think systemd bug / RFE should be opened.

Till there is no support in systemd, the workaround is to install simple script to the initrd. In Tuned it's possible by initrd overlay. Problem is that RHCOS cannot use multiple initrds or even Tuned, so they implemented it by the dracut module which installs small script into the initrd. I think it is not bad approach and much better than e.g. directly patching the initrd. The script it installs is small and harmless - it sits there and does nothing until it's activated by the kernel boot command line parameter. It's low maintenance module with no "wild constants", all it does is that it sets /sys/devices/virtual/workqueue/cpumask according to the kernel command line parameters (if provided).

I think currently there are the following options to unify this workaround for RHCOS and RHEL:

a) dracut module installed and enabled by Tuned in RHEL and by some different way in RHCOS - personally I don't have problem with it, but we will have to regenerate all the initrds on the system when we install/enable the dracut module by Tuned which could take really long time (that's what the initrd overlays are good for).
b) 3rd party package with the dracut module, problems: maintainer is needed for it, package would have to be included in to the BaseOS and installed by default in the minimal install or by some magic and there is the same problem with the images regeneration as in a)
c) dracut module upstreamed, kernel boot command line parameters controlled by Tuned or by some other tool or by hand

Personally, I like the c), but it depends whether there is a way for dracut to upstream it (i.e. whether it fits the project roadmap) or not.

Comment 5 David Tardon 2021-06-01 08:15:33 UTC

FWIW, I agree with Michal. This doesn't belong into dracut.

Comment 7 RHEL Program Management 2022-01-01 07:26:59 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.