Bug 2063930
| Summary: | [PATCH] Confine irqbalance to systems where it can do something useful | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Pat Riehecky <riehecky> |
| Component: | irqbalance | Assignee: | ltao |
| Status: | CLOSED ERRATA | QA Contact: | Jiri Dluhos <jdluhos> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | CentOS Stream | CC: | bstinson, extras-qa, jeder, jshortt, jwboyer, ltao, nhorman, ruyang, rvr, walters |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | irqbalance-1.8.0-5.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 2063926 | Environment: | |
| Last Closed: | 2022-11-15 11:18:28 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
Pat Riehecky
2022-03-14 16:25:24 UTC
Confirming the fix, as described in patch http://pkgs.devel.redhat.com/cgit/rpms/irqbalance/commit/?h=rhel-9-main&id=3c91db6799b96664c6b402522562ebbe67fa27eb # rpm -q irqbalance irqbalance-1.8.0-5.el9.x86_64 # less /usr/lib/systemd/system/irqbalance.service | grep 'CPUs' ConditionCPUs=>1 So far, so good; but when I tried on a virtual machine with a single CPU with the _old_ irqbalance, it did not start, saying this: # rpm -q irqbalance irqbalance-1.8.0-4.el9.x86_64 # systemctl start irqbalance # systemctl status irqbalance ○ irqbalance.service - irqbalance daemon Loaded: loaded (/usr/lib/systemd/system/irqbalance.service; enabled; vendor preset: enabled) Active: inactive (dead) since Fri 2022-05-27 15:30:01 CEST; 7s ago Duration: 22ms Docs: man:irqbalance(1) https://github.com/Irqbalance/irqbalance Process: 17741 ExecStart=/usr/sbin/irqbalance --foreground $IRQBALANCE_ARGS (code=exited, status=0/SUCCESS) Main PID: 17741 (code=exited, status=0/SUCCESS) CPU: 12ms May 27 15:30:01 kvm-01-guest01.lab.eng.brq.redhat.com systemd[1]: Started irqbalance daemon. May 27 15:30:01 kvm-01-guest01.lab.eng.brq.redhat.com /usr/sbin/irqbalance[17741]: Balancing is ineffective on systems with a single cpu. Shutting down May 27 15:30:01 kvm-01-guest01.lab.eng.brq.redhat.com systemd[1]: irqbalance.service: Deactivated successfully. So, it seems it has some kind of awareness of this problem by itself; aren't we double-patching a single problem here? Otherwise, I can confirm that the patch works, and with it, systemd does not even try to load irqbalance if there is only a single CPU, as planned: # rpm -q irqbalance irqbalance-1.8.0-5.el9.x86_64 # systemctl start irqbalance # systemctl status irqbalance May 27 15:50:13 kvm-01-guest01.lab.eng.brq.redhat.com systemd[1]: irqbalance daemon was skipped because of a failed condition check (ConditionCPUs=>1). So everything is OK and I am ready to stamp VERIFIED when confirmed that we want to doubly handle this situation. (In reply to Jiri Dluhos from comment #2) > Confirming the fix, as described in patch > http://pkgs.devel.redhat.com/cgit/rpms/irqbalance/commit/?h=rhel-9- > main&id=3c91db6799b96664c6b402522562ebbe67fa27eb > > # rpm -q irqbalance > irqbalance-1.8.0-5.el9.x86_64 > > # less /usr/lib/systemd/system/irqbalance.service | grep 'CPUs' > ConditionCPUs=>1 > > So far, so good; but when I tried on a virtual machine with a single CPU > with the _old_ irqbalance, it did not start, saying this: > > # rpm -q irqbalance > irqbalance-1.8.0-4.el9.x86_64 > > # systemctl start irqbalance > # systemctl status irqbalance > ○ irqbalance.service - irqbalance daemon > Loaded: loaded (/usr/lib/systemd/system/irqbalance.service; enabled; > vendor preset: enabled) > Active: inactive (dead) since Fri 2022-05-27 15:30:01 CEST; 7s ago > Duration: 22ms > Docs: man:irqbalance(1) > https://github.com/Irqbalance/irqbalance > Process: 17741 ExecStart=/usr/sbin/irqbalance --foreground > $IRQBALANCE_ARGS (code=exited, status=0/SUCCESS) > Main PID: 17741 (code=exited, status=0/SUCCESS) > CPU: 12ms > > May 27 15:30:01 kvm-01-guest01.lab.eng.brq.redhat.com systemd[1]: Started > irqbalance daemon. > May 27 15:30:01 kvm-01-guest01.lab.eng.brq.redhat.com > /usr/sbin/irqbalance[17741]: Balancing is ineffective on systems with a > single cpu. Shutting down > May 27 15:30:01 kvm-01-guest01.lab.eng.brq.redhat.com systemd[1]: > irqbalance.service: Deactivated successfully. > > So, it seems it has some kind of awareness of this problem by itself; aren't > we double-patching a single problem here? Hi Jiri, Thanks for reporting this, I think it is the same issue addressed in upstream [1]. Irqbalance do has the check in it's main function, which will fail due to one cpu, but it doesn't stop systemd from trying to start the service, which is a waste of effort. So this patch simply stop systemd from starting the service when cpu_num=1. Thanks, Tao Liu [1]: https://github.com/Irqbalance/irqbalance/pull/201 (In reply to Jiri Dluhos from comment #3) > Otherwise, I can confirm that the patch works, and with it, systemd does not > even try to load irqbalance if there is only a single CPU, as planned: > > # rpm -q irqbalance > irqbalance-1.8.0-5.el9.x86_64 > > # systemctl start irqbalance > # systemctl status irqbalance > May 27 15:50:13 kvm-01-guest01.lab.eng.brq.redhat.com systemd[1]: irqbalance > daemon was skipped because of a failed condition check (ConditionCPUs=>1). > > So everything is OK and I am ready to stamp VERIFIED when confirmed that we > want to doubly handle this situation. Yes, looks good to me. Thanks, Tao Liu Agreed; setting VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (irqbalance bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:8328 |