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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]