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

[Ulrich Windl]

On 21 Jun 2005 at 0:05, Roman Zippel wrote:

> Hi,
> 
> On Mon, 20 Jun 2005, john stultz wrote:
> 
> > > I see lots of new u64 variables. I'm especially interested how this code 
> > > scales down to small and slow machines, where such a precision is absolute 
> > > overkill. How do these patches change current and possibly common time 
> > > operations?
> > 
> > 
> > Hey Roman, 
> > 	That's a good issue to bring up. With regards to the timeofday
> > infrastructure, there are two performance concerns (though let me know
> > if I'm forgetting something):
> 
> 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?

[...]
> 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 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).

[...]
> Well, AFAICT on slower machines (older and embedded stuff) it's a serious 
> issue. The current code calculates the timeval with some simple 32bit 
> calculations. Your code introduces the nsec step, which means several 
> 64bit calculations and suddenly the overhead explodes on some machines.
> 
> 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.

> 
> I had no problems with a little more overhead, like a _few_ more 64bit 
> operations per second (and preferably add/shifts), but I'm not really 
> enthusiastic about the new code. Why don't you keep the main part 32 bits 
> (or long)? What's wrong with using timeval or timespec?
> 
> I like the concept of the a time source in your patch. m68k already uses a 
> number of timer related callbacks into machine specific code. If I could 
> replace that with a timer driver, I'd be really happy. OTOH if it requires 
> several expensive conversion between different time formats, I rather keep 
> the current code.

If everybody would be keeping the current code, we wouldn't have any problems with 
the new code (as I said before). New features do cost some power unfortunately.

Regards,
Ulrich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/