Re: [RFC] New timeofday proposal (v.A1)

From: Christoph Lameter (clameter_at_sgi.com)
Date: 12/08/04

  • Next message: Hanson, Jonathan M: "RE: Figuring out physical memory regions from a kernel module" 
    Date:	Wed, 8 Dec 2004 10:25:23 -0800 (PST)
To: john stultz <johnstul@us.ibm.com>

    On Tue, 7 Dec 2004, john stultz wrote:

    > Features of this design:
    > ========================

    > o Consolidates a large amount of code:
    > Allows for shared times source implementations, such as: i386, x86-64
    > and ia64 all use HPET, i386 and x86-64 both have ACPI PM timers, and
    > i386 and ia64 both have cyclone counters. Time sources are just drivers!

    What I would to see also included here is to provide a clean posix
    interface to these drivers. IMHO the current char interfaces to clock
    drivers should be removed. Look at SGI's mmtimer implementation in
    2.6.10-rc3. We have modified the posix interface to allow clock drivers to
    export their timer values via CLOCK_SGI_CYCLE and we are also
    now able to schedule hardware interrupts via timer_* posix functions
    utilizing CLOCK_SGI_CYCLE that are then delivered as signals to an
    application. Timer chips usually include time sources as well as the
    ability to generate periodic or single shot
    interrupts. There needs to be some way for clock drivers to cleanly
    interface with these. The API may be the posix subsystem but I do not
    like the quality of the code nor the current API for the clock drivers.

    The API for user space to clocks already exists through the posix
    standard. I would suggest to work with that standard for a way to deal
    with clocks under Linux.

    > Brief Psudo-code to illustrate the design:
    > ==========================================
    >
    > monotonic_clock()
    > now = timesource_read(); /* read the timesource */
    > ns = cyc2ns(now - offset_base); /* calculate nsecs since last hook */
    > ntp_ns = ntp_scale(ns); /* apply ntp scaling */

    These are not really functions right? timesource_read can be a direct
    memory read and the cyc2ns and ntp_scale can be reduced to some scaling
    factor?

    > Points I'm glossing over for now:
    > ====================================================
    >
    > o ntp_scale(ns): scales ns by NTP scaling factor
    > - see ntp.c for details
    > - costly, but correct.

    Please do not call this function from monotonic_clock but provide some
    sort of scaling factor that is adjusted from time to time.

    > o What is the cost of throwing around 64bit values for everything?
    > - Do we need an arch specific time structure that varies size
    > accordingly?

    I think 64 bit values are fine but then I work for a 64 bit company and
    this may just be the contextual predisposition.

    > o Some arches (arm, for example) do not have high res timing hardware
    > - In this case we can have a "jiffies" timesource
    > - cyc2ns(x) = x*(NSEC_PER_SEC/HZ)
    > - doesn't work for tickless systems

    In that case maybe the "ticks" are the timesource and not really tick
    processing per se.
    There could be a separation between "increment counter" and tick processing.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Hanson, Jonathan M: "RE: Figuring out physical memory regions from a kernel module"

    Relevant Pages

    • Re: [RFC] New timeofday proposal (v.A1)
      ... We have modified the posix interface to allow clock drivers to ... > sort of scaling factor that is adjusted from time to time. ...
      (Linux-Kernel)
    • Re: Code density and performance?
      ... Maybe I write OS code and IO drivers for an Alpha based O/S? ... the I/O buffer is provided by an entity that you do not control. ... However, C and Unix support were a sine qua non for the Alpha, ... POSIX asynchronous I/O semantics. ...
      (comp.arch)
    • Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
      ... I expect we'll come out with PCI and AGP ... Standardizing the hardware interface lowers the cost of doing an OS ... been writing and maintaining drivers for years... ...
      (Linux-Kernel)
    • Re: Beginners PC DAW suggestions needed
      ... Both programs are compatible with ASIO drivers ... so that is an option but I'd rather not have outboard gear. ... There´s already enough other stuff to learn with DAW ... SM57's if the interface supports XLR. ...
      (rec.audio.pro)
    • VESA fb weirdness in 2.6.0-test4-mm4
      ... Vesafb is announcing itself as: ... quite slow, but compared to *cough* some other fb drivers, it is at least ... # ACPI (Advanced Configuration and Power Interface) Support ...
      (Linux-Kernel)