irqbalance 2019

khz

khz

D@AU ~/Opportunist/Orwell # ./.cris/pr.run
Ich nutze das https://extensions.gnome.org/extension/1082/cpufreq/ Tool und das will kein irqbalance.
Disabling the irqbalance daemon >> https://access.redhat.com/documenta...ml/tuning_guide/interrupt_and_process_binding hatte @telefonhoerer dazu gefunden.

Habt ihr irqbalance ausgeschaltet?

Ich habe auch schon vorgeschlagen ob man das in die wiki https://linuxmusicians.com/viewtopic.php?p=104022#p104022 mit aufnehmen könnte.
Da der Artikel von RedHat aber von 2011 ist wollte ich fragen ob das veraltet ist.

Die selbe Frage habe ich auch auf https://linuxmusicians.com/viewtopic.php?p=104037#p104037 gestellt da dort mehr los ist. Das ist nur zur Füllung des Linux Bereiches. ;-)
 
D

Drumfix

|
Wenn du nicht gerade einen Server mit tausenden von Anfragen/sec betreibst, kannst du irqbalancing getrost ausschalten.
 
dbra

dbra

Ehrenpräsident des Technofreunde Ohlenburg e.V.
hab ich noch nie von gehört. bringt das abschalten was? glaub ehrlich gesagt nicht, dass das groß messbare Verbesserungen ergibt.
 
khz

khz

D@AU ~/Opportunist/Orwell # ./.cris/pr.run
QUOTE von documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/interrupt_and_process_binding

2.4. Interrupt and Process Binding

Real-time environments need to minimize or eliminate latency when responding to various events. Ideally, interrupts (IRQs) and user processes can be isolated from one another on different dedicated CPUs.
Interrupts are generally shared evenly between CPUs. This can delay interrupt processing through having to write new data and instruction caches, and often creates conflicts with other processing occurring on the CPU. In order to overcome this problem, time-critical interrupts and processes can be dedicated to a CPU (or a range of CPUs). In this way, the code and data structures needed to process this interrupt will have the highest possible likelihood to be in the processor data and instruction caches. The dedicated process can then run as quickly as possible, while all other non-time-critical processes run on the remainder of the CPUs. This can be particularly important in cases where the speeds involved are in the limits of memory and peripheral bus bandwidth available. Here, any wait for memory to be fetched into processor caches will have a noticeable impact in overall processing time and determinism.
In practice, optimal performance is entirely application specific. For example, in tuning applications for different companies which perform similar functions, the optimal performance tunings were completely different. For one firm, isolating 2 out of 4 CPUs for operating system functions and interrupt handling and dedicating the remaining 2 CPUs purely for application handling was optimal. For another firm, binding the network related application processes onto a CPU which was handling the network device driver interrupt yielded optimal determinism. Ultimately, tuning is often accomplished by trying a variety of settings to discover what works best for your organization.
Important

For many of the processes described here, you will need to know the CPU mask for a given CPU or range of CPUs. The CPU mask is typically represented as a 32-bit bitmask. It can also be expressed as a decimal or hexadecimal number, depending on the command you are using. For example: The CPU mask for CPU 0 only is 00000000000000000000000000000001 as a bitmask, 1 as a decimal, and 0x00000001 as a hexadecimal. The CPU mask for both CPU 0 and 1 is 00000000000000000000000000000011 as a bitmask, 3 as a decimal, and 0x00000003 as a hexadecimal.
Procedure 2.3. Disabling the irqbalance Daemon

This daemon is enabled by default and periodically forces interrupts to be handled by CPUs in an even, fair manner. However in real-time deployments, applications are typically dedicated and bound to specific CPUs, so the irqbalance daemon is not required.
  1. Check the status of the irqbalance daemon.
    ~]# systemctl status irqbalance
    irqbalance.service - irqbalance daemon
    Loaded: loaded (/usr/lib/systemd/system/irqbalance.service; enabled)
    Active: active (running) …

  2. If the irqbalance daemon is running, stop it.
    ~]# systemctl stop irqbalance
  3. Ensure that irqbalance does not restart on boot.
    ~]# systemctl disable irqbalance

/QUOTE
 
dbra

dbra

Ehrenpräsident des Technofreunde Ohlenburg e.V.
danke. Link anklicken kann ich selbst. hastes gemacht? irgendwelche Verbesserungen?
 
khz

khz

D@AU ~/Opportunist/Orwell # ./.cris/pr.run
Das Ziteren war bzg. deiner Frage. Ich glaube an nichts. Da in der Dokumentation ja genau das beantwortet wird IMHO.
hab ich noch nie von gehört. bringt das abschalten was? glaub ehrlich gesagt nicht, dass das groß messbare Verbesserungen ergibt.
Ja es bringt was IMHO.
 
dbra

dbra

Ehrenpräsident des Technofreunde Ohlenburg e.V.
dann werd ich das auch mal probieren...
 
dbra

dbra

Ehrenpräsident des Technofreunde Ohlenburg e.V.
so, hab es mal ausprobiert und es abgeschaltet und es bringt minimal etwas. dsplast ist durchschnittlich ca. 0,3% gesunken.
 
khz

khz

D@AU ~/Opportunist/Orwell # ./.cris/pr.run
Dachte das hat mehr was mit ~Stabilität zu tun, da - ~frei Übersetzt von access.redhat -
Interrupts werden im Allgemeinen gleichmäßig zwischen den CPUs verteilt. Dies kann die Unterbrechungsverarbeitung verzögern, indem neue Daten- und Befehlscaches geschrieben werden müssen, und führt oft zu Konflikten mit anderen Verarbeitungen auf der CPU. Um dieses Problem zu lösen, können zeitkritische Unterbrechungen und Prozesse einer CPU (oder einer Reihe von CPUs) zugeordnet werden. Auf diese Weise haben die Code- und Datenstrukturen, die zur Verarbeitung dieses Interrupts benötigt werden, die höchstmögliche Wahrscheinlichkeit, sich in den Daten- und Befehlscaches des Prozessors zu befinden. Der dedizierte Prozess kann dann so schnell wie möglich ausgeführt werden, während alle anderen unzeitkritischen Prozesse auf dem Rest der CPUs laufen. Dies kann besonders wichtig sein, wenn die beteiligten Geschwindigkeiten an der Grenze der verfügbaren Speicher- und Peripheriebusbandbreite liegen. Hier hat jede Wartezeit auf das Einlesen von Speicher in Prozessor-Caches einen spürbaren Einfluss auf die gesamte Verarbeitungszeit und den Determinismus.
?

/me dau
 
D

Doctor Jones

(8Σ
Ich hab's gar nicht erst installiert. Kommt rtirq in die Quere, WIMRE.
 
 


News

Oben