public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: john stultz <johnstul@us.ibm.com>,
	Albert Cahalan <albert@users.sourceforge.net>,
	lkml <linux-kernel@vger.kernel.org>,
	tim@physik3.uni-rostock.de, Ulrich.Windl@rz.uni-regensburg.de,
	Len Brown <len.brown@intel.com>,
	linux@dominikbrodowski.de, David Mosberger <davidm@hpl.hp.com>,
	Andi Kleen <ak@suse.de>,
	paulus@samba.org, schwidefsky@de.ibm.com, jimix@us.ibm.com,
	keith maanthey <kmannth@us.ibm.com>, greg kh <greg@kroah.com>,
	Patricia Gaughen <gone@us.ibm.com>,
	Chris McDermott <lcm@us.ibm.com>
Subject: Re: [RFC][PATCH] new timeofday core subsystem (v.A0)
Date: Tue, 14 Sep 2004 17:57:13 -0700	[thread overview]
Message-ID: <41479369.6020506@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0409141045370.6963@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> Here is a rev on the concept of a time source subsystem taking into
> account some of the feedback:
> 
> 1. add mask
> 2. rename time source so that its different from xtime
> 3. provide set_time functionality
> 4. add monotonic time support
> 5. Give some example of time sources including a function time source.
> 
> note that the original concept already includes the ability to switch time
> sources. I would think that this would be necessary especially if the CPU
> time sources frequency switches or if the system goes into sleep mode.
> 
> /****************************************************************
>  * A concept for a new timer module
>  * V2
>  *
>  * Christoph Lameter, September 14, 2003
>  ***************************************************************/
> 
> struct time_source_t {
> 	u8 type;
> 	u8 shift;
> 	u32 multiply;
> 	void *address;
> 	u64 mask;
> };
> 
> #define TIME_SOURCE_CPU 0
> #define TIME_SOURCE_MMIO32 1
> #define TIME_SOURCE_MMIO64 2
> #define TIME_SOURCE_FUNCTION 15
> 
> struct seqlock_t time_lock;	/* Protects access to time_base time_source time_mono_offset and time_source_at_base */
> u64 time_base;
> u64 time_mono_offset;
> struct time_source_t *time_source;
> u64 time_source_at_base;	/* time source value at time time_base */
> 
> u64 inline time_source_get(struct time_source_t *s) {
> 	switch (s->type) {
> 		case TIME_SOURCE_CPU	: return cycles();
> 		case TIME_SOURCE_MMIO32	: return readl(s->address);
> 		case TIME_SOURCE_MMIO64	: return readq(s->address);
> 		case TIME_SOURCE_FUNCTION: {
> 			u64 (*x)(void);
> 			x = s->address;
> 			return x();
> 		}
> }
> 
> u64 time_source_to_ns(u64 x) {
> 	return (((x-time_source_at_base) & time_source->mask)*time_source->multiply) >> time_source->shift;
> }

This seems to assume that the time souce is incrementing.  On some archs, I 
think, it decrements...
> 
> inline u64 now(void) {
> 	u64 t;
> 	unsigned long seq;
> 
> 	do {
> 		seq = read_seqbegin(&time_lock);
> 		t = time_base + time_source_to_ns(time_source_get(time_source));
> 	} while (unlikely(seq_retry(&time_lock,seq)));
> 	return t;
> }
> 
> #define now_mono() (now()+time_mono_offset)
> 
> /* Time adjustment (only possible forward, to go backwards adjust time_source->multiply and wait ...) */
> void time_adjust_skip(u64 ns) {
> 	u64 c;
> 
> 	write_seqlock(&time_lock);
> 	c = time_source_get(time_source);
> 	time_base += ns + time_source_to_ns(c);
> 	time_source_at_base = c;
> 	write_sequnlock(&time_lock);
> }

So we would do "time_adjust_skip(0);" to update time_source_at_base?
> 
> void time_adjust_slower(void) {
> 	u64 c;
> 
> 	write_seqlock(&time_lock);
> 	c = time_source_get(time_source);
> 	time_base += time_source_to_ns(c);
> 	time_source_at_base = c;
> 	time_source->multiply--;
> 	write_sequnlock(&time_lock);
> }
> 
If we do a "good" job of choosing <multiply> and <shift> this will be a "very" 
small change.  Might be better to pass in a "delta" to change it by.  Then you 
would only need one function.

> void time_adjust_faster(void) {
> 	u64 c;
> 
> 	write_seqlock(&time_lock);
> 	c = time_source_get(time_source);
> 	time_base += time_source_to_ns(c);
> 	time_source_at_base = c;
> 	time_source->multiply++;
> 	write_sequnlock(&time_unlock);
> }
> 
> /* Switch to another time source */
> void new_time_source(struct time_source_t *s) {
> 	u64 c_old;
> 	u64 c_new;
> 
> 	write_seqlock(&time_lock);
> 	c_old = time_source_get(time_source);
> 	c_new = time_source_get(s);
> 
> 	time_base += time_source_to_ns(c_old);
> 
> 	time_source_at_base = c_new;
> 	time_source = s;
> 
> 	write_sequnlock(&time_lock);
> }
> 
> struct time_source_t *make_time_source(u64 freq, int t,void *a, int bits) {
> 	struct time_source_t *s = kmalloc(sizeof(struct time_source_t));
> 
> 	s->shift = 64 - bits;
> 	s->multiply = (NSEC_PER_SEC << s->shift) / freq;
> 	s->address = a;
> 	s->type = t;
> 	s->mask = 1 << bits -1;
> }

The mask and the shift value are not really related.  The mask is a function of 
the number of bits the hardware provides.  The shift is related to the value of 
freq.  Me thinks they should not be tied together here.
> 
> void time_set(u64 ns) {
> 	u64 c;
> 
> 	write_seqlock(&time_lock);
> 	c = time_source_get(time_source);
> 	/* Adjust monotonic time base */
> 	time_mono_offset += time_base + time_source_to_ns(c) - ns;
> 	/* Setup new time base */
> 	time_base = ns;
> 	time_source_at_base = c;
> 	write_sequnlock(&time_lock);
> }
> 
> void time_init(struct time_source_t *s) {
> {
> 	write_seqlock(&time_lock);
> 	time_base = 0;
> 	time_mono_offset = 0;
> 	time_source_at_base = time_source_get(s);
> 	time_source = s;
> 	write_sequnlock(&time_lock);
> }
> 
> /* Values in use in the kernel and how they may be derived from xtime */
> #define jiffies (now()/1000000)

This assumes HZ=1000.  (Assuming there is an HZ any more, that is.)  Not all 
archs will want this value.  Possibly:
#define jiffies ((now() * HZ) / 1000000000)

> #define seconds(x) ((x)/1000000000)
> #define nanoseconds_within_second(x) ((x)%1000000000)
> #define microseconds_within_second(x) (nanoseconds_within_second(x) / 1000
> 
> u32 time(void) {
> 	return seconds(now());
> }
> 
> void gettimeofday(struct timeval *p) {
> 	u64 t=now();
> 
> 	p->tv_sec = seconds(t);
> 	p->tv_usec = microseconds_within_second(t);
> }
> 
> void clock_gettime(int clock, struct timespec *p) {
> 	u64 t=now();
> 
> 	p->tv_sec = seconds(t);
> 	p->tv_nsec = nanoseconds_within_second(t);
> }
> 
> /* Exampe of a CPU time time source */
> 
> 	make_time_source(1200000000, TIME_SOURCE_CPU, NULL, 44);
> 
> /* A memory based time source at 20Mhz 55 bits wide */
> 
> 	make_time_source(20000000, TIME_SOURCE_MMIO64, &my_timer_address, 55);
> 
> /* Example of handling a difficult time source. In SMP systems the CPU time sources are notoriously difficult to
>  * sync. If we have such a problem  then insure at least sure that the time source never goes backward.
>  */
> 
> u64 time_source_last;
> 
> u64 get_cpu_time_filtered() {
> 	u64 x;
> 	u64 l;
This will need to be "static";
> 
> 	do {
> 		l = time_source_last;
> 		x = cycles();
> 		if (x<l) return l;
> 		/* the cmpxchg is going to hurt in terms of scalability ! */
> 	} while (cmpxchg(&time_source_last, l, x) != l);
> 	return x;
> }
> 
> Generate the time_source with
> 
> 	make_time_source(1200000000, TIME_SOURCE_FUNCTION, cpu_time_filtered, 44);
> -

Ok, so now lets hook this up with interval timers:

#define ns_per_jiffie (NSEC_PER_SEC / HZ)
#define jiffies_to_ns(jiff) (jiff * ns_per_jiffie)

This function is a request to interrupt at the next jiffie after the passed 
reference jiffie.  If that time is passed return true, else false.

int schedule_next_jiffie(unsigned long ref_jiffie)
{
	u64 remains;
	u64 now_frozen = now();
	u32 jiffies_frozen = ((now_frozen * HZ) / 1000000000);

	if (jiffies_frozen > ref_jiffies)
		return 1;
	
	remains = now_frozen - jiffies_to_ns(ref_jiffie + 1);
         /*
  	 * set_timer_to_interrupt(u64 ns) is provided by the arch layer
	 */
	set_timer_to_interrupt_in(remains);
	return 0;
}

On interrupt:

	time_adjust_skip(0);
	do_timer();

Or, possibly do_timer() does the time_adjust_skip(0);

do_timer() will set up the softirq to run the timer list.  The timer list could 
could call schedule_next_jiffie, but there are SMP issues here.






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


  reply	other threads:[~2004-09-15  1:01 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-02 21:07 [RFC] New Time of day proposal (updated 9/2/04) john stultz
2004-09-02 21:09 ` [RFC][PATCH] new timeofday core subsystem (v.A0) john stultz
2004-09-02 21:11   ` [RFC][PATCH] new timeofday i386 hooks (v.A0) john stultz
2004-09-02 21:12     ` [RFC][PATCH] new timeofday i386 timesources (v.A0) john stultz
2004-09-03  1:44     ` [RFC][PATCH] new timeofday i386 hooks (v.A0) George Anzinger
2004-09-03  2:06       ` john stultz
2004-09-03  8:07       ` Ulrich Windl
2004-09-03 18:09         ` George Anzinger
2004-09-02 22:19   ` [RFC][PATCH] new timeofday core subsystem (v.A0) Christoph Lameter
2004-09-02 22:28     ` john stultz
2004-09-02 22:42       ` Christoph Lameter
2004-09-02 23:14         ` john stultz
2004-09-02 23:39           ` Christoph Lameter
2004-09-03  0:07             ` john stultz
2004-09-03  0:47               ` Christoph Lameter
2004-09-03  1:30                 ` john stultz
2004-09-03  7:43                   ` George Anzinger
2004-09-03 19:32                     ` john stultz
2004-09-03 16:18                   ` Christoph Lameter
2004-09-03 21:00                     ` john stultz
2004-09-03 22:04                       ` Christoph Lameter
2004-09-03 23:00                         ` john stultz
2004-09-04  0:11                           ` Christoph Lameter
2004-09-03  1:39   ` George Anzinger
2004-09-03  1:58     ` john stultz
2004-09-03  6:42     ` Albert Cahalan
2004-09-03  7:24       ` George Anzinger
2004-09-03 19:27         ` john stultz
2004-09-03 22:10           ` George Anzinger
2004-09-03 23:32             ` john stultz
2004-09-04  0:02               ` George Anzinger
2004-09-08 18:07                 ` john stultz
2004-09-09  0:08                   ` George Anzinger
2004-09-09  0:51                     ` john stultz
2004-09-09  3:14                       ` Christoph Lameter
2004-09-09  3:32                         ` john stultz
2004-09-09  4:31                           ` George Anzinger
2004-09-09  6:37                             ` Jesse Barnes
2004-09-09  8:09                               ` George Anzinger
2004-09-09 19:07                             ` john stultz
2004-09-09 20:49                               ` George Anzinger
2004-09-13 21:29                                 ` Christoph Lameter
2004-09-13 22:25                                   ` john stultz
2004-09-13 22:45                                     ` Christoph Lameter
2004-09-14  6:53                                       ` Ulrich Windl
2004-09-14 17:49                                     ` Christoph Lameter
2004-09-15  0:57                                       ` George Anzinger [this message]
2004-09-15  3:32                                         ` Christoph Lameter
2004-09-15  8:04                                           ` George Anzinger
2004-09-15  8:54                                             ` Dominik Brodowski
2004-09-15 17:54                                               ` George Anzinger
2004-09-15  9:12                                             ` Andi Kleen
2004-09-15 15:46                                             ` Christoph Lameter
2004-09-15 18:00                                               ` George Anzinger
2004-09-15 18:28                                                 ` Christoph Lameter
2004-09-15  6:46                                         ` Christoph Lameter
2004-09-15 16:32                                           ` john stultz
2004-09-15 16:46                                             ` Christoph Lameter
2004-09-15 17:13                                               ` john stultz
2004-09-15 17:30                                                 ` Christoph Lameter
2004-09-15 18:48                                                   ` john stultz
2004-09-15 19:58                                                     ` George Anzinger
2004-09-15 20:20                                                     ` Christoph Lameter
2004-09-16  7:02                                                     ` Ulrich Windl
2004-09-03 19:18       ` john stultz
2004-09-02 22:09 ` [RFC] New Time of day proposal (updated 9/2/04) Christoph Lameter
2004-09-02 22:22   ` john stultz
2004-09-02 22:47     ` Christoph Lameter
2004-09-03  9:54 ` Dominik Brodowski
2004-09-03 19:41   ` john stultz
2004-09-03 20:26     ` Dominik Brodowski
2004-09-03 21:05       ` john stultz
2004-09-06  6:26       ` Ulrich Windl
2004-09-06 11:56         ` Alan Cox
2004-09-07 16:14         ` Christoph Lameter
2004-09-03 15:17 ` Andi Kleen
2004-09-03 20:11   ` john stultz
2004-09-04 13:00     ` Andi Kleen
2004-09-07 16:10       ` Christoph Lameter
2004-09-07 18:24         ` George Anzinger
2004-09-07 20:55           ` Christoph Lameter
2004-09-07 21:42             ` George Anzinger
2004-09-08  6:26           ` Ulrich Windl
2004-09-08 18:25       ` john stultz
     [not found] <413850B9.15119.BA95FD@rkdvmks1.ngate.uni-regensburg.de>
     [not found] ` <1094224071.431.7758.camel@cube>
2004-09-06  6:08   ` [RFC][PATCH] new timeofday core subsystem (v.A0) Ulrich Windl
2004-09-12 17:11     ` Albert Cahalan

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=41479369.6020506@mvista.com \
    --to=george@mvista.com \
    --cc=Ulrich.Windl@rz.uni-regensburg.de \
    --cc=ak@suse.de \
    --cc=albert@users.sourceforge.net \
    --cc=clameter@sgi.com \
    --cc=davidm@hpl.hp.com \
    --cc=gone@us.ibm.com \
    --cc=greg@kroah.com \
    --cc=jimix@us.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=kmannth@us.ibm.com \
    --cc=lcm@us.ibm.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.de \
    --cc=paulus@samba.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=tim@physik3.uni-rostock.de \
    /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