On Friday 28 December 2007 01:06, Shaohua Li wrote: > > On Thu, 2007-12-27 at 21:29 -0800, Lee Howard wrote: > > Shaohua Li wrote: > > > In IOAPIC mode, interrupt priority isn't related with the pin (in your > > > case, irq 16 or 19), but the vector of the pin. How vector of a pin is > > > allocated is quite random. Usually driver who calls pci_enable_device > > > earier will get a lower priority vector. > > > > You used the words "random" and "usually". Could you elaborate on > > the > > randomness and when usually doesn't apply? > > > > So the means to prioritize a driver is to see that it gets installed > > earlier? There is no other mechanism to "reserve" pin vector > > allocations for a specific device or driver? > Currently vector is allocated when pci_enable_device is called. So which > vector is allocated depends on how many drivers already called the > routine. The first vector is 0x31, later higher priority (higher) vector > will be allocated. In latest kernel, a vector of a irq could be variable > when irq affinity is set, so it's much complex. There is no existing > method to reserve a vector for a device. 1000 interrupts/second isn't a lot on modern hardware. Indeed, many linux distros run with 1000 clock ticks/second today. I don't understand why interrupt priority has anything to do with what you are seeing. To notice such a thing, you'd have to have a lot of competing interrupts firing at the same time and the messages queued up inside the LAPIC and the processor spending a large % of its time in interrupt context. (does top(1) say that you're running a large %sys?) What is the total interrupt rate on the system when this device is doing 1000/second? Are there multiple cores on the system? If so, are the interrupts bound to certain cores or is irqbalance running? -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
