Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

From: Vojtech Pavlik (vojtech_at_suse.cz)
Date: 07/14/05

  • Next message: RVK: "Re: Open source firewalls" 
    Date:	Thu, 14 Jul 2005 14:19:50 +0200
To: Krzysztof Halasa <khc@pm.waw.pl>

    On Thu, Jul 14, 2005 at 12:25:40PM +0200, Krzysztof Halasa wrote:
    > Linus Torvalds <torvalds@osdl.org> writes:
    >
    > > And in short-term things, the timeval/jiffie conversion is likely to be a
    > > _bigger_ issue than the crystal frequency conversion.
    > >
    > > So we should aim for a HZ value that makes it easy to convert to and from
    > > the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all
    > > good values for that reason. 864 is not.
    >
    > Probably only theoretical, and probably the hardware isn't up to it...
    > But what if we have:
    > - 64-bit jiffies done in hardware (a counter). 1 cycle = 1 microsecond
    > or even a CPU clock cycle. Can *APIC or another HPET do that?

    HPETs have a fixed frequency (usually 14.31818 MHz, but that depends
    on the manufacturer).

    > - 64-bit "match timer" (i.e., a register in the counter which fires IRQ
    > when it matches the counter value)

    That's implemented in the HPET hardware.

    > - the CPU(s) sorting the timer list and programming "match timer" with
    > software timer next to be executed. Upon firing the timer, a new "next
    > to be executed" timer would be programmed into the counter's "match
    > timer".
    >
    > We would have no timer ticks when nobody requested them - the CPUs would
    > be allowed to sleep for, say, even 50 ms when no task is RUNNING. 

    -- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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: RVK: "Re: Open source firewalls"

    Relevant Pages

    • Re: Timer idea
      ... >> On ix86 machines, basic time comes from chip, read from ports. ... If HPET was a problem ... Now, with everything done in hardware, there is no problem ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC][PATCH] HPET: register additional counter-only char device
      ... enabling/disabling interrupts etc. `/dev/hpet' doesn't allow for this, ... timer. ... Allowing mmapon the hardware counter was ... Probably to prevent the HPET registers from poking with? ...
      (Linux-Kernel)
    • Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt
      ... > systems with a reliable LAPIC timer in the face of C3 do not exist ... AFAIK there are no x86 CPUs right now that do both C3 ... In theory it could be replaced with HPET if HPET had enough banks (one ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: i386 HPET code
      ... then it looks like a hardware issue. ... >the hpet is enabled, ... >any other HPET enabled systems, nor have I looked at the HPET spec, so ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: device driver for the SGI system clock, mmtimer
      ... >> mmtimer and hpet are the same hardware actually, ... hpet being the newer one. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)