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

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 10/14/05

  • Next message: Matthew Reimer: "Re: Call for performance evaluation: net.isr.direct (fwd)" 
    To: Andrew Gallatin <gallatin@cs.duke.edu>
Date: Fri, 14 Oct 2005 17:44:33 +0200

    In message <17231.50841.442047.622878@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@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.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Matthew Reimer: "Re: Call for performance evaluation: net.isr.direct (fwd)"

    Relevant Pages

    • RE: [patch 1/] timers: tsc using for cpu scheduling
      ... cpu to brother which wait mutex unlock and will do the same. ... the number of cpu clocks spent for considered task/thread for priority ... It is not need to modify TSC tick rate for cpu scheduling. ... Linux will use TSC for CPU scheduler priority calculatin. ...
      (Linux-Kernel)
    • Re: CONFIG_SLOW_TIMESTAMPS was Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft
      ... > The obvious way to implement timestamp_t is just store the CPU integrated ... adequate features to support this properly. ... You acknowledge that newer TSC implementations (and things like ... In the case of instrumentation code, ...
      (Linux-Kernel)
    • Re: [PATCH 1/2] ftrace: single CPU tracers use CPU clock
      ... and I noticed is set on my boxes with a stable TSC?? ... Line 2, on CPU 0, the idle task switches to the ls task. ... This strange trace is because the clocks between CPU 0 and 1 are off. ... box that ran this trace did have out of sync CPUS, ...
      (Linux-Kernel)
    • Re: [PATCH] Add an offset in the cyc2ns computation to fix sched_clock jumps
      ... synchronized TSC. ... takes too long to access and is not enabled before the scheduler. ... - Takes about 225 cycles per TSC read instead of 181. ... Can get a much better time precision by sending an IPI to each CPU ...
      (Linux-Kernel)
    • RE: [patch 1/] timers: tsc using for cpu scheduling
      ... > cpu to brother which wait mutex unlock and will do the same. ... I'm just asking if using the TSC ... I'm not a scheduler guy, so forgive my ignorance, but since the TSC may ... That's fine if its what you propose, I just didn't see it in your patch. ...
      (Linux-Kernel)