Re: [PATCH 0/5] clocksource patches

[Thomas Gleixner <tglx@linutronix.de>]

Roman,

On Wed, 2006-04-05 at 22:44 +0200, Roman Zippel wrote:
> What I had in mind is the _current_ setup, that e.g. the scheduler tick 
> can be generated by a clock event is a possibility, but since your 
> clockevent patch is not even in -mm, it wasn't something I had in mind 
> when I wrote this comment. This comment was specifically about the 
> _current_ way time.c sets up the timer interrupt and i8253.c sets up the 
> timer hardware.
> I also specifically said "This is not important right now, but ... 
> something to keep in mind" to indicate this needs further discussion, 
> nowhere did I ever exclude the possibility to do this via clock events, 
> but you just jumped at me with "this is wrong".

Can we stop missquoting on both sides please ? I did not jump in. I
said:

> I don't think so. Coupling the clock sources to clock event sources is
> wrong.

I unfortunately forgot to add an IMHO to every single sentence, but "I
don't think so." should have made it clear, that this is my opinion.
Maybe my knowledge of the English language is worse than I thought.

> > Why are those seperate items ?
> > 
> > Looking at the various hardware implementations there are three types of
> > devices:
> > 
> > 1. Read only devices (e.g. TSC)
> > 2. Next interrupt only devices (e.g. various timer implementations on
> > SoC CPUs)
> > 3. Devices which combine both functions
> > 
> > Building an abstraction layer which handles all device types requires
> > either 
> > 
> > - that e.g. a read only device needs to be combined with a next
> > interrupt device in some way. This introduces artifical combos of
> > functionality which can and should be handled completely seperate.
> > 
> > or 
> > 
> > - to handle all the corner cases where a device has to be handled which
> > only provides one of the functionalies. Also the selection of different
> > combinations of devices will introduce extra handling code.
> 
> Neither excludes a basic clock source abstraction, which can create any 
> kind of clock events. The basic question is should any clock source be 
> able to create every kind of clock events?

At least should the design allow that. Making restrictions in such a
layer upfront due to requirements of some known hardware devices would
be bad.

> The problem here is that we may have to synchronize reading time with the 
> timer interrupt. To make an extreme example let's assume the TSC clock is 
> updated every 1msec and the PIT generates an interrupt every 1.01msec, 
> this means jiffies is updated every 100th interrupt by 2. Also the NTP 
> error adjustment algorithm works better with small offsets, my latest 
> version compensates better for that, but a smaller offset still means a 
> smaller jitter.

Why does this require a hard coupled design ? You want a periodic event
for X with as much precision as available. Let the system choose one
which fits this best.
 
> > This is a clear seperation and there is no combined functionality.
> 
> Unfortunately it's not that simple, e.g. generating gettimeofday() 
> requires a periodic event.

It does not necessarily require a periodic event. It depends on the type
of clock source you are using and the requirements of synchronization.
The DCF-77 card in one of my boxen gives me auto sychronized time with
1nsec resolution without any periodic event. Also embedded systems which
do not use NTP do not need a periodic event for gettimeofday() when
there is a continous clock source available.

If the NTP mechanisms needs a precise periodic event, then it can
request it from the layer which manages those events.

>  At some point you have to combine 
> functionality, whether it's done inside the clocksource or by something 
> else is a different discussion. My proposal to do it inside the clock 
> source was because we don't have that "something else" yet (which may be 
> your clock events, I don't know).

So we move it into clock source because there is nothing else right
now ? That sounds like moving the mess you identified in x386 from there
to a another place.

IMO this is well worth a discussion how we want to solve this in a solid
and generic way.

> I have to skip the rest of your mail, as it's so generic and so out of 
> context that I don't really disagree with it, if there was something 
> important, please put back it into some context.

Sorry Roman, your way of discussion is not understandable to me. On one
hand you ask for explanations. When you get them, you just brush them
aside. Thanks for reminding me that my efforts to communicate with you
just produce unimportant blurb.

	tglx


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