Re: -mm merge plans for 2.6.20

[Ingo Molnar <mingo@elte.hu>]

* Roman Zippel <zippel@linux-m68k.org> wrote:

> > > > If I understand it correctly, Roman wants clockevents to be usable 
> > > > for other things aside hrtimer/dyntick, i.e. let other code request 
> > > > unused timer event hardware for special purposes. I thought about 
> > > > that in the originally but I stayed away from it, as there are no 
> > > > users at the moment and I wanted to avoid the usual "who needs that" 
> > > > comment.
> > > 
> > > Nonsense, [...]
> > 
> > why do you call Thomas' observation nonsense?
> 
> What's the point of this question? [...]

the point of my question was what it said: to ask you why you called 
Thomas' pretty fair observation 'nonsense'.

> [...] Your answer is/was in the "[...]" part.

meaning:

> > > [...] one obvious user would be the scheduler, [...]

but that is not a refutation of what Thomas said, at all. You say that 
the scheduler /could/ use such a facility. What Thomas said was that 
/there are no current users of such a facility/. It is a really simple 
(and unconditionally true) observation from Thomas. Yes, we could change 
other kernel code not directly related to high-res timers, but we chose 
not to.

[ The word 'nonsense' is in general a negative descriptor and implies 
  that what Thomas said was 'obviously false' - while in reality what we
  have is /at most/ a difference in opinion. I.e. even if our opinion 
  differs you shouldnt call his opinion "nonsense", unless you are 
  willing to prove that it's false - which you didnt do so far. I claim 
  that what Thomas said is /unconditionally true/, and i can prove it: 
  it is unconditionally true that such a new facility is not needed
  by our code, and that no other kernel code is using it at the moment -
  because the facility does not exist yet. If you misunderstood what 
  Thomas said then please point that out, or prove that his claims are 
  untrue - thanks. ]

> > Fact: there is no current user of such a facility. What we 
> > implemented, high-res timers and dynticks does not need such a 
> > facility.
> 
> Fact: there _are_ users which need a timer facility (e.g. the 
> scheduler).

this is something we are not contesting at all: that a new timer 
facility /could/ be used by /other/ kernel code, which does /not/ use it 
right now.

our point is simple: the code we add does not in itself necessiate the 
new facility, hence we didnt add it. We didnt want to impact other 
kernel code, just yet. We repeat: we agree (in theory) with such a 
facility, but we wanted to do it separately.

> > we wholeheartedly agree that such a facility 'would be nice', and 
> > 'could be used by existing kernel code' but we didnt want to chew 
> > too much at a time.
> 
> Maybe the existing code should have been cleaned up first? 

yes, we'll do that, and we have a good track record doing such cleanups. 

> Unfortunately the dynticks feature seems to more appealing than clean 
> code...

i think this accusation against us is very unfair.

> > > [...] one obvious user would be the scheduler, [...]
> > 
> > But cleaning up the scheduler tick was not our purpose with high-res 
> > timers nor with dynticks. One of your previous complaints was that the 
> > patches are too intrusive to be trusted. Now they are too simple?
> 
> Would you please stop these personal attacks?

please point it out which portion of the above two sentences you 
consider a personal attack - or if you cannot, please retract your 
baseless accusation.

Fact: you did complain in the past about the complexity and/or 
intrusiveness of our high-res timers patches - we've been working on 
getting high-res timers upstream for more than a year now.

Fact: you did complain about unused facilities in past patches of ours, 
and your feedback caused us significant extra work to remove those 
facilities, just to reintroduce them later again.

(i can provide URLs and Message-IDs for these facts)

this time around we chose the minimalistic approach, we didnt add 
anything that is not immediately needed, and we didnt want to increase 
intrusiveness by "cleaning up" other code and changing it over to the 
new facilities.

It cannot be had both ways: either we stay simpler and less intrusive, 
or we go more generic but more intrusive.

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