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 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.