lkml.org 
[lkml]   [2005]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-06-21 17:36    [W:0.079 / U:2.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site