Re: [patch] hrtimer: round up relative start time on low-res arches

[john stultz <johnstul@us.ibm.com>]

On Thu, 2006-02-16 at 15:10 +0100, Roman Zippel wrote:
> On Wed, 15 Feb 2006, john stultz wrote:
> 
> > 	I just wanted to make sure you know I'm not ignoring your suggestions.
> > I do appreciate the time you have spent, and I have been continuing to
> > work on implementing your idea. Unfortunately the code is not trivial
> > and very much hurts the readability. I expect thats a sacrifice that
> > will be necessary, but hopefully after some review cycles we'll be able
> > to come to something we both like.
> 
> The code could be cleaned up a little, but the main difference is that my 
> code is much more compact, it lacks all the redundancy of your code, which 
> makes it harder to read. My hope was here instead of putting back the 
> code redundancy to add documentation instead, which would explain the 
> subtleties.
> I actually think that the basic principle of my code is quite simple, the 
> problem is that it's a little buried inbetween how the incremental updates 
> are done in my prototype, so after a little cleaning and separating the 
> special cases, I think my code would be a lot more readable.

I'll admit I'm slow, but since it has taken me a number of weeks to sort
out exactly the details of what is being done in your implementation,
and I *still* have bugs after re-implementing it, I'd not claim your
code is simple. The potential to be very precise and efficient: yes, but
not so trivial to follow.

(This is why I cringe at the idea of trying to implement it for each
clock like you're prototype suggested.)

Maybe when I send out the patch you can suggest improvements to the
comments or other ways to better clarify the code as you suggested
above.

> > I'm hoping to have a first pass patch I can mail this week.
> 
> I'm looking forward to it.
> BTW What do you think how difficult it would be to rebase your patches on 
> my NTP4 patches? 

I'd be very much open to it, although I haven't seen any further updates
to the code since I mailed you some feedback on them. Have you had a
chance to follow up on those?

> In the end the simplification of my patches should also 
> make your patches simpler, as it precalculates as much as possible and 
> reduces the work done in the fast paths. It would avoid a lot of extra 
> work, which you currently do.

Well, I'm still cautious, since it still has some dependencies on HZ
(see equation below), which I'm trying to avoid. However I don't think
your patches keep me from getting the info I need (or atleast, the info
I think I need ;). They do seem to help close the gap between what I
want and what you want, so I think they are a good step forward.

> The main problem that I see is that you need to drop the ppm calculations, 
> the new code provides a scaled nsec value per tick (tick_nsec + time_adj) 
> and you basically only need "(update - 10^9/HZ) / cycles" to calculate the 
> new multiplier adjustment.

My test patch does this already, although for now it calculates the ntp
interval (something like "tick_nsec + time_adj" in your code) from the
ppm value. That calculation would hopefully be replaced w/ some
ntp_get_interval() call that would pull the equivalent from your code.


> You also need to drop your ntp rework, the changes to the generic code 
> should be quite simple now, basically just exporting second_overflow() 
> and creating an alternative do_timer() entry point which doesn't call 
> update_wall_time().
> 
> Besides some small cleanups I think my code is ready for some serious 
> testing, but it conflicts with your NTP changes.

If you think they're ready, mail them to the list and I'll look them
over then take a swing at re-basing my work on top of them.

thanks
-john