Messages in this thread | | | Date | Wed, 5 Apr 2006 22:44:32 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: [PATCH 0/5] clocksource patches |
| |
Hi,
On Wed, 5 Apr 2006, Thomas Gleixner wrote:
> > Thomas, I would really appreciate if you actually started to argue your > > point instead of just disagreeing with me every time. I have no problem to > > admit that I'm wrong, but it takes a bit more than you just saying it is > > so. > > I on my side would appreciate, if you would stop to take every line I > write as a personal offense.
Believe me, I'm trying very hard and I'm not easily offended, but you don't exactly make it easy. For example I get very little positive feedback from you and I'd be happy if you gave me at least constructive criticism, but you mainly just contradict me. An important indicator here is asking questions, you barely ask me any questions, which would show you're interested in my opinion and would help to avoid misunderstandings as shown further below.
> > For example above you bascially only state that your clock event source > > is superior and the correct way of doing this without any explanation why > > (and the "No, thanks." doesn't exactly imply that you're even interested > > in alternatives). > > The question arises, who is not interested in alternatives. You are well > aware about the efforts others made, but you don't even think about > working together with them. Do you really expect people to jump on your > train, when you entirely ignore their work and efforts and just propose > your own view of the world?
First off please leave other people out of this, I get along with other people quite well, it's you I continuously have these problems with. Secondly considering my contributions to John's work, it's fucking rude of you to accuse me of "not interested in alternatives" and "don't even think about working together". There is a simple reason that e.g. I'm not working on the -rt tree - lack of time. For weeks now I already had no time to work on the m68k tree, for months now I already sit on a batch of kconfig patches I'm trying to make ready. As long as your stuff doesn't appear on lkml, I consider as in development and I spent my time on more important things (which may be not so important to you).
> I did nowhere say that I'm not interested in alternative solutions. You > interpret it into my words for whatever reason. > > Your way to rip out a single statement of its context and making your > argument on that is simply annoying. > > Thats the original quote: > > How should a combo solution allow to add special hardware, which > > provides only one of the services ? By using "something else > > internally" ? No, thanks. > > It is entirely clear, that "No thanks" is related to "something else > internally".
The interesting part is that I never said "something else internally", more specifically I said "internally use another clocksource". It's you who made the generalization and then only talks about clock events, so it's easy to come to the conclusion that the "No, thanks." is not related to something specific I said, but to the generic "something else (than clock events)". I had nothing "to rip out".
> Thats the point I made further up in my first reply. It was your > proposal to combine clock sources and clock events.
This is the point were you could have saved us a lot of grief by simply asking me instead of jumping to conclusions. Nowhere in my initial mail did I make such a proposal, I'm not even mentioning clock events. The original quote:
> > AFAICT it's > > more common that the subsystem which is used to read the time is also used > > as timer (i.e. for the scheduler tick), this means the clocksource driver > > should also include the interrupt setup. > > I don't think so. Coupling the clock sources to clock event sources is > wrong.
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".
> 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? 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. These kinds of problems I had in mind when I wrote "Something like TSC should internally use another clocksource" and if you had asked I could have explained this, but I had no chance as you simply jumped to your own conclusions. :-(
> So we have two functional domains, which provide a high level interface: > > The clock source abstraction provides: > - gettimeofday() > - getmonotonic() > - settimeofday() > - clock skew adjustment functions() > > The clock event source abstraction provides: > - setup periodic events() > - setup one shot events() > - associate services (function to call on an event) to a clock event > source > > 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. 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).
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.
bye, Roman - 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/
| |