[lkml]   [2006]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: -mm merge plans for 2.6.20

* Roman Zippel <> 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-06 18:03    [W:0.111 / U:1.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site