Re: [RFC][PATCH] new timeofday core subsystem (v.A0)

George Anzinger
2004-09-15T08:06:56Z

Christoph Lameter wrote:
> On Tue, 14 Sep 2004, George Anzinger wrote:
>
>
>>>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...
>
>
> This could be handled by a function that transforms the value read from
> the counter into an incrementing value. I.e.
>
> u64 get_rev_timerval(void) {
> return 1<< 55 - readq(TIMER_PORT);
> }
>
>
>>So we would do "time_adjust_skip(0);" to update time_source_at_base?
>
>
> There is no reason to update time_source_at_base unless adjustments need
> to be done or a danger exists of the counter wrapping around (16 bit
> counter?)

Yes, for example the pm counter is 24 bits. A lot of platforms have 32 bit
counters...
>
>
>>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.
>
>
> These are the raw routines. Higher level function could translate a delta
> into the appropriate adjustments.
>
>
>>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.
>
>
> They are related because the maximum shift for a 64 bit value without
> loosing bits is 64 - number of significant bits. This basically insures
> maximum precision when scaling the counter.

Lets assume the pm counter which has 24 bits. This means your shift is 40 bits.
In "s->multiply = (NSEC_PER_SEC << s->shift) / freq;" you will have an overflow.
Here you need to keep (NSEC_PER_SEC << s->shift) in 64 bits AND multiply must
also be 32 bits or less. I really don't think you can choose the scale so easily.
>
>
>
>>>/* 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)
>
>
> Right. I just thought of the standard case HZ=1000.
>
>
>>>u64 get_cpu_time_filtered() {
>>> u64 x;
>>> u64 l;
>>
>>This will need to be "static";
>
>
> Nope. time_source_last is the global. l is just a copy of
> time_source_last.

Right, I miss read the function. cycles() should be now() if I am reading this
right.
>
>
>>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.
>
>
> One could do this but we want to have a tickless system. The tick is only
> necessary if the time needs to be adjusted.

I really think a tickless system, for other than UML systems, is a loosing
thing. The accounting overhead on context switch (which increases as the number
of switchs per second) will cause more overhead than a periodic accounting tick
once a respectable load appears. The periodic accounting tick has a flat
overhead that does not depend on load.
>
> But you are right there is the need for timer event scheduling that is
> not included yet. This should be a method of the time source.
>
I am not sure that is the right thing to do here. For example, on SMP systems
today we have a timer event interrupt per cpu. This is much more scaleable and
not so easy to do if we tie it to the time source. All we need is a reasonably
accurate short term counter.
--
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