MSI (Message Signaled Interrupts) támogatás

Linux

A modern hardverek gyártóinak van egy nagy problémájuk. Túl sok a láb. A gyártók egyik fő problémája, és a chip gyártás egyik legköltségesebb része a belső huzalozás kivezetése, azaz a csatlakozó felület kialakítása. A chipnek egyre kisebbeknek kell lenniük, hiszen egyre több alkatrésznek kell egy lapon elférnie. A pár négyzetcentiméteres felületen egyre nehezebb ezt megvalósítani. Gondoljunk csak a mai processzorok méretére és lábainak számára. Nem ritka a 400+ lábú processzor. Ezért a hardver tervezők fontos szempontnak tartják, hogy a tervezés során egyre kevesebb legyen a kivezetések száma. Ez nem csak a processzoroknál figyelhető meg, elég ha csak a serial ATA-ra gondolunk. Ott is cél, hogy a sok pin-nel rendelkező, széles adatkábelt igénylő csatolófelületet lecseréljék. A lábcsökkentés másik célja a megszakítási vonalak (interrupt lines) eltávolítása. A (relatíve) új hardverek úgy próbálják meg eliminálni az interrupt line-okat (és közben egy újabb lépést tenni az "örökség mentes (legacy free) környezet felé") , hogy bevezetnek egy új PCI busz technológiát, az MSI-t. Az MSI (Message Signaled Interrupts) tulajdonképpen nem csinál mást, mint a megszakítás kérést (interrupt) direkt az adat buszra helyezi, mint az adat folyam részét. Az MSI-kész eszközök ebben a rendszerben úgy jelenthetik be megszakítási igényüket, hogy sajátos értékű adatot írnak egy megadott címre. Az operációs rendszer képes ezeket az írásokat elfogni (trap), és ennek megfelelően elküldeni a megszakítást.



Egy szép napon az összes eszköz képes lesz használni az MSI-t (ez az elképzelés) és akkor nem lesz szükség a továbbiakban az elkülönített megszakítási vonalakra. Az MSI relatíve új elgondolás, és a hardver támogatás is épp csak elkezdődött hozzá. A Linux kernel jelenleg még nem támogatja az MSI-t.

Tom Nguyen (Intel) egy patchen dolgozik, amelyet nem rég a z LKML-re postázott. A patch célja, hogy megvalósítsa az MSI támogatást a Linux kernelben. Az MSI működéséről, és a Linuxos implementációról bővebben az MSI-HOWTO-ban olvashatsz.

Az MSI patch egyelőre messze van attól, hogy bekerüljön a mainline kernelbe, mert elég komoly előkészítő munka kell ahhoz, hogy beolvasztható legyen. Ahhoz, hogy a 2.6-os kernel megszakításkezelő kódját átdolgozzák már nincs elegendő idő. Valószínű, hogy a korai 2.7 kernelbe fog bekerülni a patch.

A patch itt.

( trey | 2003. 08. 24., v – 15:01 )

hat szomoru vagyok, hogy neked ez jon le az irasbol. sajnallak, de azert meg szerencse, hogy vannak ilyen jol kepzett szakemberek, akik ellenervenk bevagnak egy egy oldalas pdf -et, aminek a lenyeg osszefoglalhato egy mondatban, es akar a 8 eves fiam is levonna a kovetkeztetest:

"a hardveres megoldas jobb, mint a szoftveres."

Komoly munka, majd ha lesz idom, en is fogok hasonlo "vilagraszolo" bejelenteseket tenni.

Pl. a SCSI jobb mint az IDE, a HW gyorsitott 3D gyorsabb, mint a szoftveres, stb.

Koszi, hogy beidezted, mert tenyleg komoly tanulmany :-) de tenyleg (rotfl)

( szaszg | 2003. 08. 24., v – 22:28 )

Természetesen igazad van, de DE

ne felejtsük el, hogy az Intel architectura-ban élünk. Itt azt hiszem üdvözölni kell minden olyan megoldást, ami megpróbálja felszámolni a korábbi nyûgöket (jelen esetben, az AT alaplapon elhelyezett 16 bemenetes CPU-t tehermentesítõ megszakításvezérlõt, illetve annak túlélõ (krokodil) utódjait) elimináló megoldásokat... Így a PCI-os megosztható IRQ-t, valamint az MSI-t is (habár ennek a leírás alapján elsõdleges célja a proci lábszámának csökkentése volt).

Amúgy nem hinném, hogy a "hardveres" IRQ lábak annyira meggyorsítanák a dolgot, hiszen a mostani processzorok sebessége messze a perifériák sávszélessége fölött van (ld. pl. 1., 2., 3., X. szintû cache...), valamint, a "hardveres" kérés esetén is el kell végezni mindazokat a taszk-váltáshoz kapcsolódó dolgokat, amiket el _kell_ végezni... :-)

Mán bocsi. a load-nak, mi köze a megszakításkezeléshez?? Ha jól tudom összvissz egy NMI-d van!!!

Zsiráf