[PATCH 00/12] hrtimer patches

[PATCH 00/12] hrtimer patches

[Roman Zippel]

Hi,

Here is new version of the hrtimer patches sorted by priority. I dropped 
the remaining time patch, the const patch doesn't produce a larger kernel 
with gcc3 and I also added the acks so far.
I consider the first four patches the most important and the remaining 
patches simple enough, that I think they're still 2.6.16 material.

bye, Roman

Re: [PATCH 00/12] hrtimer patches

[Ingo Molnar]

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

> Here is new version of the hrtimer patches sorted by priority. I 
> dropped the remaining time patch, the const patch doesn't produce a 
> larger kernel with gcc3 and I also added the acks so far. I consider 
> the first four patches the most important and the remaining patches 
> simple enough, that I think they're still 2.6.16 material.

i only consider the first two patches to be 2.6.16 material. The other 
patches avoid a ->get_time() call per timer interrupt - that's noise at 
most ...

	Ingo

Re: [PATCH 00/12] hrtimer patches

[Roman Zippel]

Hi,

On Tue, 14 Feb 2006, Ingo Molnar wrote:

> > Here is new version of the hrtimer patches sorted by priority. I 
> > dropped the remaining time patch, the const patch doesn't produce a 
> > larger kernel with gcc3 and I also added the acks so far. I consider 
> > the first four patches the most important and the remaining patches 
> > simple enough, that I think they're still 2.6.16 material.
> 
> i only consider the first two patches to be 2.6.16 material. The other 
> patches avoid a ->get_time() call per timer interrupt - that's noise at 
> most ...

It's two get_time() calls and I don't consider it noise, they are wasting 
time with unnecessary hardware accesses.

bye, Roman

Re: [PATCH 00/12] hrtimer patches

[Ingo Molnar]

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

> > > Here is new version of the hrtimer patches sorted by priority. I 
> > > dropped the remaining time patch, the const patch doesn't produce a 
> > > larger kernel with gcc3 and I also added the acks so far. I consider 
> > > the first four patches the most important and the remaining patches 
> > > simple enough, that I think they're still 2.6.16 material.
> > 
> > i only consider the first two patches to be 2.6.16 material. The other 
> > patches avoid a ->get_time() call per timer interrupt - that's noise at 
> > most ...
> 
> It's two get_time() calls and I don't consider it noise, they are 
> wasting time with unnecessary hardware accesses.

Nobody complained about it so far (other than you) or has measured it, 
so IMO there's no pressing need and it's simply too late in the cycle to 
touch core timer code like that. 2.6.16 is really cooling down now.

Furthermore, this is known subtle code, and it has accumulated some good 
QA by now. Your first patch-queue already introduced races (the 
"optimize hrtimer_get_remaining" patch) - which you considered to be
part of the "minimum amount of patches for 2.6.16" too.

Dont take this as some negative feedback: most of them look fine to me,
and it's really great that you are contributing to the code, but please
be a bit more patient.

	Ingo

Re: [PATCH 00/12] hrtimer patches

[Roman Zippel]

Hi,

On Tue, 14 Feb 2006, Ingo Molnar wrote:

> > It's two get_time() calls and I don't consider it noise, they are 
> > wasting time with unnecessary hardware accesses.
> 
> Nobody complained about it so far (other than you) or has measured it, 
> so IMO there's no pressing need and it's simply too late in the cycle to 
> touch core timer code like that. 2.6.16 is really cooling down now.

Well, most developer don't care about older hardware anymore, on recent 
hardware it's indeed a nonissue, so I'm not really suprised nobody 
complained.
For me the patch is important enough that it should be seriously 
considered for 2.6.16 and not just rejected like this. Sorry, that I'm a 
bit late, but the hrtimer was merged without warning and I can't just drop 
everything to fix other people's code.

bye, Roman