On 09/15/08 17:13, Seth Goldberg wrote: > > > Quoting Bill Holler, who wrote the following on Mon, 15 Sep 2008: > >> On 09/15/08 16:56, Seth Goldberg wrote: >>> >>>>> As far as I can tell the interface we use to allocate the interrupt >>>>> will not share a LEVEL and EDGE interrupt. If this is true we can >>>>> use an edge-triggered interrupt knowing Solaris will not share the >>>>> irq. >>>>> Is this true? >>>> I *think* so; but I defer to Seth, who has more of this arcane >>>> code in his head than I. >>> >>> That's true, but you have to be very careful -- if for whatever >>> reason, the HPET is sharing an interrupt line with another device, >>> you risk introducing regressions (driver attach failures) by >>> effectively making that line exclusive to the HPET. >>> >>> --S >> >> The HPET ACPI table is used to map the HPET. The HPET >> defines which I/O APIC lines its timer(s) can route to. >> IThe HPET spec does not guaranty these lines are not shared. >> The DSDT does not provide any more info about the HPET. >> >> Using level-triggered interrupts instead of edge-triggered >> added about 3 to 4 microseconds to the HPET's interrupt service >> routine due to the need to read and write the HPET's status. >> Considering Deep C-State latency is around 160 to 1000 >> microseconds, the added latency may not be significant. > > Have you considered an ultra lightweight ISR for the HPET to get > around the heavyweight stuff in cmnint? (It may not be practical, but > it's an option for super-low-latency handling). > > --S
This may be the way to go, but only if we can use an edge-triggered interrupt. Accesses to the HPET are really slow compared to on-CPU accesses, so this might not buy us much if we use level- triggered interrupts. We also have to investigate how expensive it is to reprogram the I/O APIC to target the next waking CPU every time. Thank you, Bill
