Messages in this thread | | | Date | Tue, 21 Jun 2005 17:13:38 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3) |
| |
Hi,
On Tue, 21 Jun 2005, Ulrich Windl wrote:
> > You don't really answer the core question, why do you change everything to > > nanoseconds and 64bit values? > > Because just multiplying the microseconds by one thousand doesn't really provide a > nanosecond clock, maybe?
What are you trying to tell me?
> > With -mm you can now choose the HZ value, so that's not really the > > problem anymore. A lot of archs even never changed to a higher HZ value. > > Did you ever do an analysis how this affected clock quality? See > comp.protocols.time.ntp for all the complains about broken kernels (I think Redhat > had it first, then the others followed).
So how exactly does this patch fix this?
> > So now I still like to know how does the complexity change compared to the > > old code? > > You can have a look at the code. That's the point where you can decide about > complexity. I haven't looked closely, but I guess it was O(1) before, and now also > is O(1).
You guess or you know?
> > As m68k maintainer I see no reason to ever switch to your new code, which > > might leave you with the dilemma having to maintain two versions of the > > timer code. What reason could I have to switch to the new timer code? > > I never knew the 68k has such a poor performance.
Usually it's code that either is efficient or performs badly.
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/
| |