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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox