Initial 6.1 questions

Danial Thom danial_thom at
Mon Jun 12 19:58:02 UTC 2006

--- Robert Watson <rwatson at> wrote:

> On Mon, 12 Jun 2006, Danial Thom wrote:
> > first, why is the default for HZ now 1000? It
> seems that 900 extra clock 
> > interrupts aren't a performance enhancement.
> This is a design change that is in the process
> of being reconsidered.  I 
> expect that HZ will not be 1000 in 7.x, but
> can't tell you whether it will go 
> back to 100, or some middle ground.  There are
> a number of benefits to a 
> higher HZ, not least is more accurate timing of
> some network timer events. 
> Since I don't have my hands in the timer code,
> I can't speak to what the 
> decision process here is, or when any change
> might happen, but I do expect to 
> see some change.

Will anything break if I tweek this downward?

> > Running a simple test with a traffic
> generator (firing udp packets to a 
> > blackhole), the system overhead with a single
> processor goes up from 10% to 
> > 15% when running a kernel with SMP enabled
> (and nothing else different). I 
> > have ITR set to 6000 interrupts per second.
> That seems like an awful lot of 
> > overhead. Is there some problem running an
> SMP-enabled kernel when only 1 
> > processor is present, or is there really 50%
> extra overhead on an SMP 
> > scheduler? I'll have a dual core in a few
> days to test with.
> I don't know about the particular number, but
> there is a significant overhead 
> to building in SMP support currently -- in
> particular, you pick up a lot of 
> atomic instructions which increases the cost of
> locking operations even 
> without contention.  Some of that overhead
> reduces as the workload goes up, as 
> there's coalescing of work under locked
> regions, reduced context switch rates 
> as work is performed in batches, etc.  There is
> currently extremely active 
> work in the area of reducing the overhead of
> scheduling and context switching, 
> being driven in part by the 32-processor
> support in Sun4v.  I don't expect to 
> see large portions of that merged to RELENG_6,
> but it will be in RELENG_7. 
> Again, not my area of expertise, but there is
> work going on in this area.
> Finally, there is a known performance problem
> involving loopback network 
> traffic and preemption, which results in
> additional context switches.  You may 
> want to try disabling preemption and see if/how
> that impacts your numbers. 
> There has been seen quite a bit of discussion
> of this problem, and I expect to 
> see a solution for it in the near future.  This
> problem does not manifest for 
> remote traffic, only loopback traffic.

I'm sending this traffic from an external device,
receiving on an em controller with blackhole set
to 1. So I assume this loopback issue doesn't
apply to this test?


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the freebsd-performance mailing list