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

From: john stultz
Date: Mon Jun 20 2005 - 12:12:52 EST

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at