Kernel 2.6 und hohe CPU-Last bei Netzwerk I/O

[gmo18t]

Hi,

könnte es sein, daß der 2.6er Version des Netzwerktreibers (enet.c) mehr CPU Last verursacht als die 2.4er Version ?

Ich habe die Sourcen einmal verglichen und folgendes festgestellt:

1. Version 2.4.27 von enet.c

die TX/RX-Buffer des SCC2 werden direkt über "skb_buf->data" abgewickelt, so daß kein zusätzlicher Speichertransfer (memcpy) stattfindet.
D.h. die jeweiligen "skb_buf->data"-Pointer werden sowohl in die "TxBD table" als auch in die "RxTB table" des Parameter RAMs übernommen, so daß kein Umkopieren von Buffer-Daten nötig ist.

2. Version 2.6.9 von enet.c

die RX-Buffer des SCC2 werden im neuen Verfahren (dma-mapping) mit "dma_alloc_coherent()" angelegt und jeweils nach Empfang per "eth_copy_and_sum()" (also per memcpy) in entsprechende "skb_buf->data"-Bereiche umkopiert.

Beim Senden gibt's keinen Unterschied, da wird wieder der "skb_buf->data"-Pointer direkt in die TxBD table des Parameter-RAMs übernommen ohne daß ein Zwischenpuffer verwendet wird.

3. Vermutung

durch das zusätzliche Kopieren beim Empfang von Daten geht die CPU-Last hoch !
Gerade weil ich das in Zusammenhang mit dem Movierplayer beobachtet habe, weil da ja beim TS-Abspielen der Daten-Empfang mit annähernd voller Bandbreite stattfindet und somit eine beträchtliche Anzahl an memcpy()s auf die CPU losgelassen werden.

Oder ist das doch keine große Belastung für ne 66MHz CPU ?

Erst dachte ich, daß hier irgendwie ein DMA-Problem vorliegt, da der 2.6er Kernel beim Booten irgenwas mit "badness in dma_alloc_init()" rummosert.
Aber da das Netzwerk ja letztendlich funktioniert, sollte ja auch mit "dma_alloc_coherent()" in "enet.c" ein Rx-Buffer angelegt worden sein und die Kommunikation mit dem SCC2 funktionieren (auch DMA technisch).

4. Idee

ganz einfach, die 2.6er Version von "enet.c" wirder auf das "Empfangs-Verhalten" der 2.4er Version zurücktrimmen

Aber bevor ich da dran rumbasteln will, würde ich gerne die Meinung von den Experten hören, inwieweit dies überhaupt Sinn macht und ob's da Fallen geben könnte...

- GMo -

[petgun]

hi,

3. Vermutung

durch das zusätzliche Kopieren beim Empfang von Daten geht die CPU-Last hoch !

...habe keine Ahnung davon..aber trotzdem eine Vermutung: Es findet kein DMA-Transfer statt...es gibt zuviele IRQ's und die IRQ-Serviceroutine beansprucht die CPU zu stark...Stichworte:BH-Treiber...Block-IRQ. Vergiss es, wenn's nicht passt...jeder blamiert sich so gut wie er kann.

cu,
peter

--
Jede Katastrophe beginnt mit einer Vermutung.

[gmo18t]

hi,
...habe keine Ahnung davon..aber trotzdem eine Vermutung: Es findet kein DMA-Transfer statt...es gibt zuviele IRQ's und die IRQ-Serviceroutine beansprucht die CPU zu stark...Stichworte:BH-Treiber...Block-IRQ.

dachte ja auch erst an sowas, aber allein der SCC2 schreibt/liest die Puffer immer per DMA (jedenfalls so wie's im Treiber konfiguriert ist - und da hat sich im Vergleich zur 2.4er Version nix geändert). Natürlich kommen da Interrupts, um den Vollzug eines gefüllten bzw. geleerten Puffers zu melden. Daraufhin sollte der Puffer nur noch an den Netwerkcore von linux weitergereicht werden - ohne Umkopieren - sonst macht DMA ja sowieso nicht so recht Sinn ...

- GMo -

[Npq]

Hmm, das ist glaube ich der Patch von wojo von dem du sprichst.

Der ist erstmal außen vorgelassen worden. Kannst du aber gerne wieder reinbauen, ich weiß, daß er da ein paar Dinge geändert hat (unter anderem auch eine Funktion für den dvb2eth-Treiber eingebaut, der deswegen auch noch fehlt), vermutlich hat er das dabei mit angepaßt.

Warum das nicht upstream gegangen ist kann ich nicht sagen, müßte man wojo mal fragen.

[gmo18t]

Hi,

hätt ich's gleich gewußt, daß es schon im 2.4er so gepatcht war ...

Aber nachdem ich nun ein "enet.c" analog der 2.4er Version gemacht hatte, ist der Kernel gestürzt.

Da muß ich mir mal was überlegen -> glaube, ich hab keinen Fehler im Coding (denkt man ja immer), weil ich's 100 mal gecheckt hab ...

- GMo -

[Houdini]

Schau Dir Deine Änderungen mal im Bezug auf cachable/uncachable memory an (möglicherweise is dir ein invalidate_dcache_range() durch die Lappen gegangen)
Eine andere Änderung zw. 2.4 und 2.6 ist, dass 2.4 mit _pa(adr) arbeitet und 2.6 je nachdem mit vaddr oder bufadr.
Vielleicht ist da ja noch was bei Dir faul.

Houdini

[gmo18t]

Schau Dir Deine Änderungen mal im Bezug auf cachable/uncachable memory an (möglicherweise is dir ein invalidate_dcache_range() durch die Lappen gegangen)
Eine andere Änderung zw. 2.4 und 2.6 ist, dass 2.4 mit _pa(adr) arbeitet und 2.6 je nachdem mit vaddr oder bufadr.
Vielleicht ist da ja noch was bei Dir faul.
Houdini

im 2.6er linux wurde das MM ja stark überarbeitet. Trotzdem hat sich bei der Senderoutine nichts geändert, dort wird "__pa(adr)" verwendet. Nur bei der Initialiserung der Buffer für den Empfang ist nun anstelle von "__pa(adr)" die Funktion "va = dma_alloc_coherent(..., &pa,...)", wobei eine virtuelle (va) und eine pyhs. Adresse (pa) zurückgeliefert werden.

In der 2.4er Version werden an dieser Stelle "sk_buff"-Buffer erzeugt, wobei "sk_buff->data" eigentlich die virtuelle Adr. und mit "__pa(sk_buff->data)" die zugehörige phys. Adr. in's Paramter RAM geschrieben wird. Und genau das ist ja die entscheidende Taktik, um das "memcpy()" zu umgehen.

Somit hab ich doch eigentlich die richtige Ausgangsposition für die 2.6er Version, wenn ich das so aus der 2.4er übernehme, den "__pa(adr) geht doch auch beim Senden !?

Soweit meine Logik und obwohl mir beim"cachable memory" nichts durch die Lappen gegangen ist, resetet die Box

Also muß es einen Unterschied in Bezug auf "dma_alloc_coherent()" geben, der sich aber lediglich beim Datenempfang auswirkt.

Na ja, vielleicht hat jemand ne Idee. Ich versuch's jetzt mal mit "gefakten" sk_buff-Buffers mit "data-"Bereichen, die per "dma_alloc_coherent()" erzeugt sind. Die kann ich lokal im Treiber verstecken und dann per "skb_clone()" oder Ähnlichem an die Netzwerkschicht durchreichen, so daß nur mit einer Referenz auf den data-Bereich gearbeitet, d.h. ein "memcpy()" wird eingespart.

- GMo -

[Houdini]

Wenn Du mir Deinen aktuellen File zur Verfügung stellst, schau ich ihn mir an. Vielleicht fällt mir was auf..

Houdini

[gmo18t]

Hi,

@houdini: prima - schreib mir doch bitte ne PN, wohin ich das File per Mail schicken kann.

- GMo -

[Houdini]

Hallo gmo,

check mal ob
>> skb_put(rx_skb,pkt_len-4); <<
wirklich dahingehört, bzw ob skb_put nicht auf dem neuen skb ausgeführt werden sollte.
rx_skb ist zu der Zeit ja schon fertig.
aber ich sehe gerade im 2.4 Treiber ist das auch so, grübel.

Was gibts denn für einen oops?
Lass Dir mal die Adressen der cep->rx_bd_base und der bdp->cbd_bufaddr
ausgeben, vielleicht stimmt da was nicht.
Möglicherweise gibt es auch noch ein Problem, da der Datenbereich (der ja aus der DMA kommt) nicht cachable ist, aber in netif_rx das so erwartet wird.

Houdini, dem sonst nichts mehr einfällt

[gmo18t]

Hallo gmo,

check mal ob
>> skb_put(rx_skb,pkt_len-4); <<
wirklich dahingehört, bzw ob skb_put nicht auf dem neuen skb ausgeführt werden sollte.
rx_skb ist zu der Zeit ja schon fertig.
...

und weil fertig, ab damit zum Netzwerk core und Datenlänge auf "pkt_len-4" gesetzt

Aber ist eigentlich egal, ich hab die Variante mit "clone_skb()" hinbekommen, die läuft jetzt prima und DMA schreibt nun direkt in
"sk_buff".

Leider ändert das nicht wirklich was an der CPU-Last, womit die Problematik nun eindeutig in den Innereien des 2.6er Kernels zu suchen ist

- GMo -

[petgun]

hi,

Leider ändert das nicht wirklich was an der CPU-Last, womit die Problematik nun eindeutig in den Innereien des 2.6er Kernels zu suchen ist

..und sowas wie 'top' kann Deine These nicht untermauern? Welcher Prozess ist denn das ? Ich wuerde mit dem Problem zu Obi gehen ;-)

cu,
peter

--

[gmo18t]

hi,
..und sowas wie 'top' kann Deine These nicht untermauern? Welcher Prozess ist denn das ? Ich wuerde mit dem Problem zu Obi gehen ;-)

die 100% CPU Zeit ist kein These, die ist Realität
Mit "top", sieht man nur, daß 90% vom SYSTEM verbraten werden, da ist kein verdächtiger Prozeß zu finden ...

und Obi hat das bestimmt auch schon längst festgestellt, wäre aber toll, wenn er sich mal melden würde.

- GMo -

[petgun]

hi,

..wäre aber toll, wenn er sich mal melden würde.

...macht Obi wieder Hausbesuche?...ich muss da immer hingehen..

cu,
peter