Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #145085 > unrolled thread

irqbalance?

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  irqbalance? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-03 15:23 +0200
    Re: irqbalance? Friedemann Stoyan <usenet@ip6-mail.de> - 2025-05-03 16:45 +0200
    Re: irqbalance? Stefan Reuther <stefan.news@arcor.de> - 2025-05-04 10:16 +0200
      Re: irqbalance? Gregor Szaktilla <spam0.sz@ktilla.de> - 2025-05-04 22:30 +0200
        Re: irqbalance? Stefan Reuther <stefan.news@arcor.de> - 2025-05-05 17:44 +0200
      Re: irqbalance? Markus Schaaf <mschaaf@elaboris.de> - 2025-05-05 18:58 +0200
      Re: irqbalance? Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-05-05 23:09 +0200
        Re: irqbalance? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-06 21:19 +0200
      Re: irqbalance? Kay Martinen <usenet@martinen.de> - 2025-05-05 23:19 +0200
        Re: irqbalance? Christian Garbs <mitch@cgarbs.de> - 2025-05-06 07:00 +0000
        Re: irqbalance? Stefan Reuther <stefan.news@arcor.de> - 2025-05-06 20:50 +0200

#145085 — irqbalance?

Hallo,

auf einigen meinen (Debian-)Systemen habe ich irqbalance installiert
(https://github.com/Irqbalance/irqbalance). Das Upstream-Repo ist
lebendig, das Debian-Paket nicht wirklich auf dem allerneuesten Stand
(u.a. fehlt eine native systemd-Unit).

Ich frage mich: Braucht es das überhaupt? Sollte nicht der Kernel
schon darauf achten, dass auch die Interrupts eines Prozesses auf die
Prozessorkerne verteilt werden?

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [next] | [standalone]

#145088

Marc Haber wrote:

> Ich frage mich: Braucht es das überhaupt? Sollte nicht der Kernel
> schon darauf achten, dass auch die Interrupts eines Prozesses auf die
> Prozessorkerne verteilt werden?

Gute Frage. Ich nutze es nicht (mehr). Die moderne Hardware hat eh so viele
Queues (Netzwerk + NVMe), dass das gut über alle Kerne verteilt wird.

mfg Friedemann

[toc] | [prev] | [next] | [standalone]

#145097

Am 03.05.2025 um 15:23 schrieb Marc Haber:
> auf einigen meinen (Debian-)Systemen habe ich irqbalance installiert
> (https://github.com/Irqbalance/irqbalance). Das Upstream-Repo ist
> lebendig, das Debian-Paket nicht wirklich auf dem allerneuesten Stand
> (u.a. fehlt eine native systemd-Unit).
> 
> Ich frage mich: Braucht es das überhaupt? Sollte nicht der Kernel
> schon darauf achten, dass auch die Interrupts eines Prozesses auf die
> Prozessorkerne verteilt werden?

Die Interrupts eines Prozesses willst du eigentlich gerade nicht
pauschal über die Prozessorkerne verteilen, damit die nicht ständig den
Cache hin und her schieben müssen.

Ganz so einfach ist es nicht, da eine ideale Lösung zu finden. OK,
"alles, was zum Netzwerkzugriff gehört" auf einen Core, nämlich denen,
der die Netzwerkpakete empfängt, aber was, wenn der anfängt, mit dem
Massenspeicher zu reden? Und was, wenn ich drei Cores habe, die Netzwerk
machen?

Spontan hätte ich da auch kluge Algorithmen im Kernel erwartet, genauso,
wie der Kernel kluge Speicherallokationsalgorithmen und kluge
Massenspeicherschedulingalgorithmen enthält. Beim kurzen Querlesen finde
ich zumindest keine Beschreibung, was irqbalance überhaupt macht, und
was das Defizit im Kernel ist, was es behebt.


  Stefan

[toc] | [prev] | [next] | [standalone]

#145131

Am 04.05.25 um 10:16 schrieb Stefan Reuther:
> ... Beim kurzen Querlesen finde
> ich zumindest keine Beschreibung, was irqbalance überhaupt macht, und
> was das Defizit im Kernel ist, was es behebt.

Vielleicht stammt das aus der Windows-Welt und hieß dort früher 
RAM-Doubler ...?

SCNR

Gregor

-- 
Dreck ist Materie am falschen Platz. (Schotty)

[toc] | [prev] | [next] | [standalone]

#145154

Am 04.05.2025 um 22:30 schrieb Gregor Szaktilla:
> Am 04.05.25 um 10:16 schrieb Stefan Reuther:
>> ... Beim kurzen Querlesen finde
>> ich zumindest keine Beschreibung, was irqbalance überhaupt macht, und
>> was das Defizit im Kernel ist, was es behebt.
> 
> Vielleicht stammt das aus der Windows-Welt und hieß dort früher
> RAM-Doubler ...?

Das hört heute auf den Namen 'zram' bzw. 'zswap' und funktioniert ganz
ausgezeichnet.

Ganz ehrlich, die IRQs nach gewissen Regeln an CPU-Kerne zuzuordnen,
ergibt schon Sinn. Nur fehlt mir halt die Beschreibung des konkreten
Defizits und der konkreten Lösung, um beurteilen zu können, ob so ein
Userspace-Programm die richtige Lösung ist.


  Stefan

[toc] | [prev] | [next] | [standalone]

#145155

Am 04.05.25 um 10:16 schrieb Stefan Reuther:

> Spontan hätte ich da auch kluge Algorithmen im Kernel erwartet, genauso,
> wie der Kernel kluge Speicherallokationsalgorithmen und kluge
> Massenspeicherschedulingalgorithmen enthält. Beim kurzen Querlesen finde
> ich zumindest keine Beschreibung, was irqbalance überhaupt macht, und
> was das Defizit im Kernel ist, was es behebt.

Ich weiß nicht, ob es sich um das gleiche irqbalance handelt, 
aber bei OpenWRT wird das häufiger benutzt. Vermutlich auch eher 
zum Experimentieren, ohne jedesmal einen neuen Kernel flashen und 
booten zu müssen.

MfG

[toc] | [prev] | [next] | [standalone]

#145159

Stefan Reuther <stefan.news@arcor.de> wrote:
> Spontan hätte ich da auch kluge Algorithmen im Kernel erwartet,
> genauso, wie der Kernel kluge Speicherallokationsalgorithmen und kluge
> Massenspeicherschedulingalgorithmen enthält. Beim kurzen Querlesen
> finde ich zumindest keine Beschreibung, was irqbalance überhaupt
> macht, und was das Defizit im Kernel ist, was es behebt.

Es wird zumindest noch weiter entwickelt, siehe
https://github.com/Irqbalance/irqbalance.

Was natürlich nicht viel zu bedeuten hat. 'Orrible und Windoze werden
ebenfalls weiter entwickelt ;-).

-- 
It rubs the AI on its devices or else it gets the hose again

[toc] | [prev] | [next] | [standalone]

#145174

Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
>Stefan Reuther <stefan.news@arcor.de> wrote:
>> Spontan hätte ich da auch kluge Algorithmen im Kernel erwartet,
>> genauso, wie der Kernel kluge Speicherallokationsalgorithmen und kluge
>> Massenspeicherschedulingalgorithmen enthält. Beim kurzen Querlesen
>> finde ich zumindest keine Beschreibung, was irqbalance überhaupt
>> macht, und was das Defizit im Kernel ist, was es behebt.
>
>Es wird zumindest noch weiter entwickelt, siehe
>https://github.com/Irqbalance/irqbalance.

Dass das Upstream-Repo durchaus lebendig ist, schrieb ich in der zwei
Artikel entfernten Threaderöffnung schon.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#145160

Am 04.05.25 um 10:16 schrieb Stefan Reuther:
> Am 03.05.2025 um 15:23 schrieb Marc Haber:
>> auf einigen meinen (Debian-)Systemen habe ich irqbalance installiert
>> (https://github.com/Irqbalance/irqbalance). Das Upstream-Repo ist
>> lebendig, das Debian-Paket nicht wirklich auf dem allerneuesten Stand
>> (u.a. fehlt eine native systemd-Unit).
>>
>> Ich frage mich: Braucht es das überhaupt? Sollte nicht der Kernel
>> schon darauf achten, dass auch die Interrupts eines Prozesses auf die
>> Prozessorkerne verteilt werden?

Ist das hier (https://linux.die.net/man/1/irqbalance) das 
gleiche/gemeinte oder etwas anderes?

> Die Interrupts eines Prozesses willst du eigentlich gerade nicht
> pauschal über die Prozessorkerne verteilen, damit die nicht ständig den
> Cache hin und her schieben müssen.

Sind das nicht INT's, also Software-Interrupts?

> Ganz so einfach ist es nicht, da eine ideale Lösung zu finden. OK,
> "alles, was zum Netzwerkzugriff gehört" auf einen Core, nämlich denen,
> der die Netzwerkpakete empfängt, aber was, wenn der anfängt, mit dem
> Massenspeicher zu reden? Und was, wenn ich drei Cores habe, die Netzwerk
> machen?

>  Beim kurzen Querlesen finde
> ich zumindest keine Beschreibung, was irqbalance überhaupt macht, und
> was das Defizit im Kernel ist, was es behebt.

Ich verstehe die o.g. Beschreibung (man page) so das es da nur um 
Hardware-Interrupts und deren Verteilung; oder NICHT-verteilung; auf die 
CPU-Kerne geht. Womit man dann z.b. Massenspeicher und Netzwerk auf 
getrennte Kerne legen könnte. Oder geht es vielleicht (auch) um die
'--powerthresh=<threshold>' option um Kerne schlafen legen zu können?

Allerdings verstehe ich dabei auch nicht wie die '--banscript=<script>' 
Option da (schnell genug) arbeiten könnte.

-snip-
     Execute the specified script for each irq that is discovered, 
passing the sysfs path to the associated device as the first argument, 
and the irq vector as the second. An exit value of 0 tells irqbalance 
that this interrupt should balanced and managed as a normal irq, while a 
non-zero exit code indicates this irq should be ignored by irqbalance 
completely (see --banirq above). Use of this script provides users the 
ability to dynamically select which irqs get exluded from balancing, and 
provides an opportunity for manual affinity setting in one single code 
point.
-snap-

Pro IRQ ein shellscript aufrufen dürfe jeden Aufruf wohl um das 
tausendfache verlangsamen. Das kann's wohl nicht sein. Aber was dann?
Vielleicht eine art Lookup-tabelle die geladen und angewendet wird 
(weil/in sysfs)?

So weit ich erinnere ist mir irqbalance in der Prozesstabelle meines 
Proxmox mal aufgefallen. Dort könnte ich mir schon vorstellen das z.b. 
bei einem 2(Sockel)*6(Kerne) System (BTDT) bestimmte kerne für I/O 
"reserviert" werden könnten. Oder das (lt. man page) man in einer 
Situation mit nur 4 Kernen unter last die 2. CPU schlicht in 
Stromspar-modus versetzten könnte, und die restlichen 2 kerne der 1. CPU 
für I/O "balance'd"

Vielleicht alles nur Blödsinn, vielleicht fehlt auch noch was das obige 
"Verteilung" umsortieren könnte, oder es fehlt absichtlich?

Bye/
   /Kay

-- 
Posted via Leafnode

[toc] | [prev] | [next] | [standalone]

#145161

Mahlzeit!

Kay Martinen <usenet@martinen.de> wrote:
> Am 04.05.25 um 10:16 schrieb Stefan Reuther:

> Ist das hier (https://linux.die.net/man/1/irqbalance) das 
> gleiche/gemeinte oder etwas anderes?

Ich wollte schon schimpfen, dass das Projekt keinerlei Dokumentation
hat, aber die Manpage liegt auch im git-Repo, ich hab sie nur
übersehen:

https://github.com/Irqbalance/irqbalance/blob/master/irqbalance.1

Ja, das ist das gesuchte.

>>  Beim kurzen Querlesen finde
>> ich zumindest keine Beschreibung, was irqbalance überhaupt macht, und
>> was das Defizit im Kernel ist, was es behebt.
> 
> Ich verstehe die o.g. Beschreibung (man page) so das es da nur um 
> Hardware-Interrupts und deren Verteilung; oder NICHT-verteilung; auf die 
> CPU-Kerne geht. Womit man dann z.b. Massenspeicher und Netzwerk auf 
> getrennte Kerne legen könnte. Oder geht es vielleicht (auch) um die
> '--powerthresh=<threshold>' option um Kerne schlafen legen zu können?
> 
> Allerdings verstehe ich dabei auch nicht wie die '--banscript=<script>' 
> Option da (schnell genug) arbeiten könnte.
> 
> -snip-
>     Execute the specified script for each irq that is discovered, 
> passing the sysfs path to the associated device as the first argument, 
> and the irq vector as the second. An exit value of 0 tells irqbalance 
> that this interrupt should balanced and managed as a normal irq, while a 
> non-zero exit code indicates this irq should be ignored by irqbalance 
> completely (see --banirq above). Use of this script provides users the 
> ability to dynamically select which irqs get exluded from balancing, and 
> provides an opportunity for manual affinity setting in one single code 
> point.
> -snap-
> 
> Pro IRQ ein shellscript aufrufen dürfe jeden Aufruf wohl um das 
> tausendfache verlangsamen. Das kann's wohl nicht sein. Aber was
> dann?

Da das Laden und Starten eines Shellscripts höchstwahrscheinlich
Interrupts auslöst, wäre das eine endlose Rekursion :)

> Vielleicht eine art Lookup-tabelle die geladen und angewendet wird 
> (weil/in sysfs)?

Für mich liest sich das so, als ob das neu "neu entdeckte" IRQs
betrifft: Wenn irqbalance z.B. das erste Mal seit Start einen IRQ 5
"sieht", dann fragt es das Shellscript, ob es sich drum kümmern soll.
Die Entscheidung im Shellskript kann sich der Admin selbst
zusammenbauen, basierend auf IRQ-Nummer, Mondphase und sonstigem.

Ich denke auch mal, dass die IRQs generell nicht abgefangen werden und
ein IRQ erst nachträglich "entdeckt" wird – vermutlich werden
regelmäßig die Kernel-Counter für ausgeführte Interrupts abgefragt.
Da hinkt zwangsweise leicht hinterher.

> Vielleicht alles nur Blödsinn, vielleicht fehlt auch noch was das obige 
> "Verteilung" umsortieren könnte, oder es fehlt absichtlich?

Ich denke mal, dass die eigentliche Verteilung der Interrupts im
Kernel liegt.  Dort wird irqbalance dann Bescheid geben und sagen "den
IRQ 5, denn mach mal immer auf CPU 3+4 und nirgendwo anders".

Da müsste man sich mal das Kernel-Interface genauer angucken, ob es da
CPU-Masken oder sowas gibt.

(Ich wollte gerade sagen "keine Ahnung, wo man da anfängt zu suchen",
 aber der irqbalance-Sourcecode bietet sich an :)

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
"Die grosse Mehrzahl unserer Importe kommt von ausserhalb des Landes"
                                                    (George W. Bush)

[toc] | [prev] | [next] | [standalone]

#145172

Am 05.05.2025 um 23:19 schrieb Kay Martinen:
> Am 04.05.25 um 10:16 schrieb Stefan Reuther:
>> Die Interrupts eines Prozesses willst du eigentlich gerade nicht
>> pauschal über die Prozessorkerne verteilen, damit die nicht ständig den
>> Cache hin und her schieben müssen.
> 
> Sind das nicht INT's, also Software-Interrupts?

Am Ende ist "die Interrupts eines Prozesses" schon mal vereinfacht; ich
habe das als "Hardware-Interrupts, die im Auftrag eines Prozesses
ausgelöst wurden" gelesen und gemeint.

Wenn mein Prozess am Netzwerk lauscht, wird irgendwann die Netzwerkkarte
sagen "hey, da ist was für dich", und das Ergebnis dieses
Hardware-Interrupts wird meinem Prozess zugestellt. Und da wäre das
schön, wenn der Interrupt direkt an meinem CPU-Kern ankommen würde, und
nicht erst ein teurer Inter-Prozessor-Interrupt nebst Cache-Migration
nötig wäre.

> -snip-
>     Execute the specified script for each irq that is discovered,
> passing the sysfs path to the associated device as the first argument,
> and the irq vector as the second. An exit value of 0 tells irqbalance
> that this interrupt should balanced and managed as a normal irq, while a
> non-zero exit code indicates this irq should be ignored by irqbalance
> completely (see --banirq above). Use of this script provides users the
> ability to dynamically select which irqs get exluded from balancing, and
> provides an opportunity for manual affinity setting in one single code
> point.
> -snap-
> 
> Pro IRQ ein shellscript aufrufen dürfe jeden Aufruf wohl um das
> tausendfache verlangsamen. Das kann's wohl nicht sein. Aber was dann?
> Vielleicht eine art Lookup-tabelle die geladen und angewendet wird
> (weil/in sysfs)?

Ich lese das als: es wird geprüft, welche IRQs überhaupt in Benutzung
sind. Es gibt ja heutzutage mehr als die 2x8 Stück des Intel 8259A. Wenn
man weiß, dass ein "IRQ 142" nicht in Benutzung ist und niemals feuern
wird, muss man ihn auch nicht berücksichtigen.


  Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web