Messages in this thread | | | Subject | Re: [patch] hrtimer: round up relative start time on low-res arches | From | john stultz <> | Date | Thu, 16 Feb 2006 11:06:10 -0800 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |