Re: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux