From: George Anzinger <george@mvista.com>
To: Mark Gross <mgross@linux.jf.intel.com>
Cc: Arjan van de Ven <arjanv@redhat.com>,
Geoff Levand <geoffrey.levand@am.sony.com>,
high-res-timers-discourse@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] high-res-timers patches for 2.6.6
Date: Mon, 14 Jun 2004 13:48:43 -0700 [thread overview]
Message-ID: <40CE0F2B.2000408@mvista.com> (raw)
In-Reply-To: <200406140828.08924.mgross@linux.intel.com>
Mark Gross wrote:
> On Friday 11 June 2004 15:33, George Anzinger wrote:
>
>>I have been thinking of a major rewrite which would leave this code alone,
>>but would introduce an additional list and, of course, overhead for
>>high-res timers. This will take some time and be sub optimal, so I wonder
>>if it is needed.
>
>
> What would your goal for the major rewrite be?
> Redesign the implementation?
> Clean up / re-factor the current design?
> Add features?
Mostly I would like to make it "clean" enough to get the community to accept it.
As I look at the current implemtation, the biggest intrusion into the "normal"
kernel is in the timer list area. Thus, my thinking is to introduce a second or
slave list which would only be used by HR timers. This list would be "checked"
by putting a "normal" i.e. add_timer, timer in place to mark the jiffie that a
HR timer was to expire in. The "check" code would then set up the HR interrupt
to expire the timer.
I am also considering removing a lot of the ifdefs one way or another. AND, I
think I can make the whole thing configureable at boot time just as the
pm/TSC/etc. timers are.
>
> I've been wondering lately if a significant restructuring of the
> implementation could be done. Something bottom's up that enabled changing /
> using different time bases without rebooting and coexisted nicely with HPET.
>
> Something along the lines of;
> * abstracting the time base's, calibration and computation of the next
> interrupt time into a polymorphic interface along with the implementation of
> a few of your time bases (ACPI, TSC) as a stand allown patch.
Uh, is this something like the current TSC/ pmtimer/ HPET/ PIT selection code in
the x86? Or do you have something else in mind here. Given the goal of
integration with and inclusion in the kernel.org kernel, I don't want to wander
too far from what they are doing now.
> * implement yet another polymorphic interface for the interrupt source used by
> the patch, along with a few interrupt sources (PIT, APIC, HPET <-- new )
> * Implement a simple RTC-like charactor driver using the above for testing and
> integration.
I am not sure what wants to be done here. I have to keep in mind that x86 is
only one of many archs. I would like to keep it as simple as possible in this
area. See the include/linux/hrtime.h file for the arch interface we are now using.
> * Finally a patch to integrate the first 3 with the POSIX timers code.
>
> What do you think?
>
>
> --mgross
>
> -
> 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/
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2004-06-14 20:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-10 1:49 [ANNOUNCE] high-res-timers patches for 2.6.6 Geoff Levand
2004-06-10 2:40 ` William Lee Irwin III
2004-06-10 8:40 ` eric.piel
2004-06-10 9:08 ` William Lee Irwin III
2004-06-10 10:04 ` Arjan van de Ven
2004-06-11 0:02 ` George Anzinger
2004-06-11 6:22 ` Arjan van de Ven
2004-06-11 22:11 ` George Anzinger
2004-06-11 22:33 ` George Anzinger
2004-06-12 14:01 ` Arjan van de Ven
2004-06-14 15:28 ` Mark Gross
2004-06-14 20:48 ` George Anzinger [this message]
2004-06-14 22:20 ` Mark Gross
2004-06-15 0:21 ` George Anzinger
2004-06-15 16:04 ` Mark Gross
2004-06-16 22:33 ` George Anzinger
2004-06-17 19:35 ` Mark Gross
2004-06-21 22:50 ` Geoff Levand
2004-06-21 23:17 ` George Anzinger
2004-06-22 17:37 ` Geoff Levand
2004-06-22 18:05 ` Stephen Hemminger
2004-06-22 23:07 ` George Anzinger
2004-06-23 0:15 ` Geoff Levand
[not found] ` <40D8CF88.4050608@am.sony.com>
2004-09-03 1:35 ` [ANNOUNCE] high-res-timers patch Geoff Levand
2004-11-04 20:41 ` Geoff Levand
2004-06-23 16:23 ` [ANNOUNCE] high-res-timers patches for 2.6.6 Mark Gross
2004-06-21 23:29 ` Mark Gross
2004-06-12 0:24 ` Karim Yaghmour
2004-06-14 20:57 ` George Anzinger
2004-06-21 3:14 ` Karim Yaghmour
2004-06-21 21:33 ` George Anzinger
2004-06-22 4:50 ` Karim Yaghmour
2004-06-21 23:13 ` Stephen Hemminger
2004-06-21 23:22 ` Randy.Dunlap
-- strict thread matches above, loose matches on Subject: below --
2004-06-10 12:46 Dave Hylands
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=40CE0F2B.2000408@mvista.com \
--to=george@mvista.com \
--cc=arjanv@redhat.com \
--cc=ganzinger@mvista.com \
--cc=geoffrey.levand@am.sony.com \
--cc=high-res-timers-discourse@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mgross@linux.jf.intel.com \
/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