cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c

[Robert Watson]

On Thu, 20 Oct 2005, M. Warner Losh wrote:

> In message: <4357AAFE.2070002 at samsco.org>
>            Scott Long <scottl at samsco.org> writes:
> : However, I'd like to revisit the HZ=1000 decision for 7-CURRENT.
>
> At Timing Solutions, we run with HZ=1000 to reduce the latency for 
> interacting with serial devices (since we have highly synchronous 
> protocols that are spoken over them).  Other than that, we've seen no 
> performance differences between HZ=100 and HZ=1000 in other areas of our 
> systems.  We have noted a small increase in overhead with 1000, but 
> since we have plenty of CPU to burn, we burn a little to get better 
> latencies...  We'll likely tune the number based on our experience, so 
> changing the default HZ won't impact us.

I've seen reports of TCP improvements as a result of more precise timing, 
but I've also seen reports of minor performance reduction as a result of 
the increased overhead.  Some of the problems here were reduced by 
removing naive uses of callouts that ran every tick in order to run their 
own job scheduler which then selected to run jobs only every now and then. 
This still exists in some of the RPC-related code in NFS, and needs to be 
addressed.  It's also important for Xen, because in Xen it's desirable to 
only run per-domain clock ticks if there's work to do, so there are 
optimizations in Xen to use programmable timers for callouts rather than 
running them frequently in order to avoid having to run all the domains 
every time a timer tick fires.

Revisiting the 1000hz decision does make sense, but there are real 
trade-offs here: higher accuracy in timing potentially improves the 
behavior of retransmission and drop detection for network services in high 
performance environments.  With time scales on packet processing events 
being on the order of a millionth of a second, things are a lot different 
than previously.

Robert N M Watson