Call for performance evaluation: net.isr.direct (fwd)

[Matthew Reimer]

Poul-Henning Kamp wrote:

> In message <17231.50841.442047.622878 at grasshopper.cs.duke.edu>, Andrew
> Gallatin
>  writes:
> 
>> > >What if somebody were to port the linux TSC syncing code, and use it
>> > >to decide whether or not set kern.timecounter.smp_tsc=1?  Would you
>> > >object to that?
>> > 
>> > Yes, I would object to that.
>> > 
>> > Even to this day new CPU chips come out where TSC has flaws that
>> > prevent it from being used as timecounter, and we do not have (NDA)
>> > access to the data that would allow us to build a list of safe
>> > hardware.
>>
>>Bear in mind that I have no clue about timekeeping.  I got into this
>>just because I noticed using a TSC timecounter reduces context switch
>>latency by 40% or more on all the SMP platforms I have access to:
>>
>>1.0GHz dual PIII : 50% reduction vs i8254
>>3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254)
>>2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254)
> 
> The solution is not faster but less reliable timekeeping, the
> solution is to move the scheduler(s) away from using time as an
> approximation of cpu cycles.

Would the hardware performance counters be suitable for that, at least on 
processors that have them?

Matt