* Roman Zippel <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
