[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:

> On Wed, 6 Dec 2006, Thomas Gleixner 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? Fact: there is no current
user of such a facility. What we implemented, high-res timers and
dynticks does not need such a facility.

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

> [...] 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?

We'll clean up the scheduler tick and profiling too, but not now.

> [...] the current scheduler tick emulation is rather ugly [...]

i disagree with you and it's pretty low-impact anyway. There's still
quite many HZ/tick assumptions all around the time code (NTP being one
example), we'll deal with those via other patches.

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 14:15    [W:0.078 / U:78.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site