Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932259AbWBPOLL (ORCPT ); Thu, 16 Feb 2006 09:11:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932347AbWBPOLL (ORCPT ); Thu, 16 Feb 2006 09:11:11 -0500 Received: from scrub.xs4all.nl ([194.109.195.176]:6547 "EHLO scrub.xs4all.nl") by vger.kernel.org with ESMTP id S932259AbWBPOLK (ORCPT ); Thu, 16 Feb 2006 09:11:10 -0500 Date: Thu, 16 Feb 2006 15:10:51 +0100 (CET) From: Roman Zippel X-X-Sender: roman@scrub.home To: john stultz cc: Ingo Molnar , Andrew Morton , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [patch] hrtimer: round up relative start time on low-res arches In-Reply-To: <1140036234.27720.8.camel@leatherman> Message-ID: References: <1139827927.4932.17.camel@localhost.localdomain> <20060214074151.GA29426@elte.hu> <20060214122031.GA30983@elte.hu> <20060215091959.GB1376@elte.hu> <1140036234.27720.8.camel@leatherman> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2318 Lines: 47 Hi, 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'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? 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. 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. 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. bye, Roman - 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/