Re: dziwne nowe klawiatury

Radosław Sokół <Radoslaw.Sokol@polsl.pl> wrote:

>> Taka, że mając dwa rdzenie każdy z nich może obsługiwać inne przerwanie,
>> np. poprzez smp_affinity albo IRQ balancing.

> A co niby szkodzi, że przerwanie dwóch urządzeń zostanie
> zgłoszone tą samą linią?

To, że do procesorów przypisujesz właśnie linię przerwania:

/proc/irq/*/smp_affinity

więc 2 urządzenia na tej samej lini == dwa urządzenia, których
przerwania obsługiwane są tym samym procesorem/rdzeniem/wirtualną
jednostką HT, co z kolei prowadzić może do przeciążenia danego rdzenia
(softIRQ) przy niewykorzystaniu drugiego.

> Obsługa przerwania zajmuje drobny moment, zaraz potem
> rusza asynchroniczna procedura obsługi przerwania urucha-
> miana na pierwszym wolnym procesorze, a nie na tym, który
> odebrał przerwanie.

Nie na pierwszym wolnym - właśnie o tym mówię. To IRQ balance w kernelu
stosuje politykę round-robin, ale softIRQ (procedury obsługi przerwania)
można wykonywać na konkretnej jednostce przypisanej na sztywno w
powyższy sposób (lub demonem irqbalance działającym w userspace, który
właśnie zmienia affinity tak, aby rozłożyć w miarę po równo).
Nota bene bez affinity ani kernelowego IRQ balance wszystkie procedury
obsługi lecą na pierwszą jednostkę.

> Zaraz zaraz. W PCI? Bo w PCIe o ile mi wiadomo można
> zgłaszać przerwanie tyko przez MSI (normalne INTx jest
> emulowane w MSI).

Hm, wydaje mi się, że jest dokładnie odwrotnie - to normalne przerwanie
jest mapowane na MSI przez mostek PCI-Express (oraz PCI-X):

        Capabilities: [a0] HyperTransport: MSI Mapping

ale nawet jeśli tak nie jest, to ja się pytałem o odbieranie a nie
zgłaszanie; oto karta w PCIe:

07:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (rev 06)
        Subsystem: Intel Corporation Unknown device 1082
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at e8420000 (32-bit, non-prefetchable) [size=128K]
        Memory at e8400000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at 5000 [size=32]
        [virtual] Expansion ROM at e2200000 [disabled] [size=128K]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
        Capabilities: [e0] Express Endpoint IRQ 0

a oto jej przerwania:

 19: 1728 216455 160465 802383756 IO-APIC-level eth3

jak widzisz korzystam z IO-APIC a nie MSI, gdyż z tego co gdzieś
czytałem MSI cechuje niższa responsywnoć.

Gdybym włączył sobie tę opcję:

config PCI_MSI
        bool "Message Signaled Interrupts (MSI and MSI-X)"
        depends on PCI
        depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
        help
           This allows device drivers to enable MSI (Message Signaled
           Interrupts). Message Signaled Interrupts enable a device to
           generate an interrupt using an inbound Memory Write on its
           PCI bus instead of asserting a device IRQ pin.

to w miejscu IO-APIC-level pojawiłoby się MSI właśnie.

I tu właśnie moje pytanie - czy rzeczywiście MSI powoduje większe
opóźnienia niż APIC?

-- 
Tomek                                    http://tccs.sourceforge.net/
http://pld-linux.org/                    http://vfmg.sourceforge.net/