Re: -mm merge plans for 2.6.20

[Ingo Molnar <mingo@elte.hu>]

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

> > > > > [...] 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.
> 
> I didn't say "/could/", the scheduler _needs_ such a facility. [...]

i disagree that the scheduler unconditionally 'needs' such a facility. 
The scheduler clock is pretty special and has other requirements and 
constraints than generic timekeeping clocks. It /might/ and /could/ 
utilize such an infrastructure, but it's not at all clear that it 
'needs' such a facility.

in any case, i very much entertain the possibility of more synergy in 
this space, but it's far from obvious and it's definitely not 
unconditionally 'necessary'. The scheduler and profiling code certainly 
worked for 15 years without such synergy. What we concentrated on in 
this patchset is high-resolution timers and dynticks, not scheduler or 
profiler clock cleanups. We cleaned up everything that we impacted 
directly, but we also tried to limit the scope of the changes wherever 
possible.

	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/