[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
On Tue, 2006-12-05 at 20:30 -0800, Andrew Morton wrote: 
> I don't have a clue which review comments remain unaddressed - do you recall?
> I never saw an item-by-item accounting of my own (extensive) review
> comments, actually. And then an avalanche of new stuff got sent and I
> didn't have time to go through it all at the same level of detail.

Arjan did a review of the replacement and I'm in the process to go
through that and Romans comments again. I'll add a complete list of the
review issues and the resolution state. Sorry that this was delayed, but
I was busy regression testing and hunting nasty details in the last

> So yeah, I don't have a lot of confidence from that POV either. But otoh,
> I'm confident that Ingo and Thomas will competently and promptly address
> regressions, so the risk factor isn't too bad. And changing APIC and
> timekeeping code sure is risky.

Timekeeping is mostly untouched and the APIC change was done to solve
real world issues:

- lapic verification gets stuck for ever
- lapic timer runs too fast

> > In the long term IMO this might need a major rework, the basic problem I
> > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how
> > to dynamically manage multiple timer.
> I'm not sure I understand that. Are you referring to multiple,
> concurrently-operating hardware clock sources? <wonders how that could
> work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
> isn't it?

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. Granted
that clockevents is not perfect, but it's rather self contained and has
no user space exposure, so it can be replaced by something better


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