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

[john stultz <johnstul@us.ibm.com>]

On Sat, 2005-06-18 at 14:02 +0200, Roman Zippel wrote:
> On Fri, 17 Jun 2005, john stultz wrote:
> 
> > o Uses nanoseconds as the kernel's base time unit
> 
> Maybe I missed it, but was there ever a conclusive discussion about the 
> perfomance impact this has?
> 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):
	1. timer interrupt processing overhead
	2. gettimeofday() syscall performance

On smaller systems, timer interrupt processing is a concern, with the
shift to HZ=1000, we got a number of complaints from folks w/ old 486s
where time would drift due lost ticks. This would happen when something
(usually IDE in PIO mode) would disable interrupts and they would miss a
ton of timer interrupts. Also the impact of running the timekeeping code
10x more frequently was seen in a number of cases.

With the new infrastructure, timekeeping is all done via a soft-timer
outside of interrupt context. In fact, the timekeeping soft-timer is
setup to run every 50ms instead of every ms. This should help overall
performance on slower systems using high HZ values.

As for gettimefoday() syscall performance, I one had some numbers, but I
would need to re-create them. I'll see if I can grab a slower box and
give you some hard numbers. The gettimeofday() path is fairly
streamlined and should be pretty straight forward in the patch (see
kernel/timeofday.c), so let me know if you have specific concerns. 

There will probably be a bit of a drop, but I have some ideas for
cacheing a precomputed timeval in the timekeeping soft-timer if its a
serious issue.

thanks
-john