From: Clemens Ladisch <clemens@ladisch.de>
To: Jaswinder Singh Rajput <jaswinderlinux@gmail.com>
Cc: the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Hungry for hardware timers
Date: Tue, 07 Sep 2010 09:59:31 +0200 [thread overview]
Message-ID: <4C85F0E3.2050908@ladisch.de> (raw)
In-Reply-To: <AANLkTiktFQWvz-TzewKYEd1wtEbe3cVFjFca4dFtUTCV@mail.gmail.com>
Jaswinder Singh Rajput wrote:
> I am investigating how many hardware timers are available for kernel,
> system applications and user applications for x86 platforms.
Why would you want to have a separate timer for your application?
> Is there any help available for it so that systems developers can use
> a hook up an interrupt and use any hardware timer.
The kernel is supposed to abstract away the hardware; just use POSIX
timers.
> In APIC timer, but each core is having only one timer and it is
> already utilized by Linux :
> ... APIC TMICT: 00002078
> ... APIC TMCCT: 00000b5f
> ... APIC TDCR: 00000003
Having per-CPU timers allows the kernel to avoid synchronizing between
CPUs.
> HPET have 3 timers :
> [ 0.328157] hpet: ID: 0x8086a201, PERIOD: 0x429b17f
> [ 0.328315] hpet: CFG: 0x3, STATUS: 0x0
> [ 0.328472] hpet: COUNTER_l: 0x6ff120, COUNTER_h: 0x0
> [ 0.329006] hpet: T0: CFG_l: 0x138, CFG_h: 0xf00000
> [ 0.329165] hpet: T0: CMP_l: 0x701baa, CMP_h: 0x0
> [ 0.329324] hpet: T0 ROUTE_l: 0x0, ROUTE_h: 0x0
> [ 0.329483] hpet: T1: CFG_l: 0x0, CFG_h: 0xf00000
> [ 0.330006] hpet: T1: CMP_l: 0xffffffff, CMP_h: 0x0
> [ 0.330166] hpet: T1 ROUTE_l: 0x0, ROUTE_h: 0x0
> [ 0.331005] hpet: T2: CFG_l: 0x0, CFG_h: 0xf00800
> [ 0.331168] hpet: T2: CMP_l: 0xdf751c, CMP_h: 0x0
> [ 0.331328] hpet: T2 ROUTE_l: 0x0, ROUTE_h: 0x0
>
> T0 and T2 is already used by Linux and T1 is used for RTC
T2 shouldn't be used. What does /proc/interrupts say?
> System 8254 timer have 3 timers but it seems it is also used by Linux :
> [ 4923.510233] 0: 83ae 1: 1102 2: 37f2
> [ 4923.510251] 0: 8382 1: d10 2: 37dc
That thing is horribly slow; nobody would want to use this, if possible.
Regards,
Clemens
next prev parent reply other threads:[~2010-09-07 8:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-07 6:32 Hungry for hardware timers Jaswinder Singh Rajput
2010-09-07 7:59 ` Clemens Ladisch [this message]
2010-09-07 8:23 ` Jaswinder Singh Rajput
2010-09-07 9:05 ` Clemens Ladisch
2010-09-07 9:57 ` Jaswinder Singh Rajput
2010-09-07 10:55 ` Clemens Ladisch
2010-09-17 5:48 ` Jaswinder Singh Rajput
2010-09-17 7:38 ` Clemens Ladisch
2010-12-10 4:47 ` Jaswinder Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C85F0E3.2050908@ladisch.de \
--to=clemens@ladisch.de \
--cc=jaswinderlinux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.