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

[Poul-Henning Kamp]

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.

>However, if the linux solution is not
>correct, then somebody with timekeeping knowledge needs to get 
>involved.  Is this you?

The linux "solution" is not correct, and timekeeping knowledge I
have, but the solution is in the scheduler where my clue is limited.

>BTW, is an algorithm like Solaris' the "best compromise" you mention
>above?  Or is it just keeping the TSC in sync?  They seem to maintain
>a high resolution timer based on tsc, and keep it in sync every
>second, and fixup drift on different cpus, and the TSC
>being reset after suspend/resume.
>http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/os/timestamp.c

Solaris don't change the tsc frequency by a factor 8 without giving
the OS a chance to know about it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.