From owner-freebsd-performance@FreeBSD.ORG Mon Jun 12 19:58:02 2006 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A23CB16A49E for ; Mon, 12 Jun 2006 19:58:02 +0000 (UTC) (envelope-from danial_thom@yahoo.com) Received: from web33306.mail.mud.yahoo.com (web33306.mail.mud.yahoo.com [68.142.206.121]) by mx1.FreeBSD.org (Postfix) with SMTP id 0026B43D4C for ; Mon, 12 Jun 2006 19:58:01 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: (qmail 72454 invoked by uid 60001); 12 Jun 2006 19:57:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ys3GSJpJnj3CE+8YNrTvInDIozOoouRPWoBQpcQ1zTRHu1P79Ffw3bff+00nClo9q1ABVNnWM3I1hGbgC9VxJFl+OJ/tT8W54OKjzEbnhaT3SlMSSLokLqtzGjXjf07dn/LYL4m08cPJTqnHFvfGVMDS/gxmxcLihx0HqCFAsjM= ; Message-ID: <20060612195754.72452.qmail@web33306.mail.mud.yahoo.com> Received: from [65.34.182.15] by web33306.mail.mud.yahoo.com via HTTP; Mon, 12 Jun 2006 12:57:54 PDT Date: Mon, 12 Jun 2006 12:57:54 -0700 (PDT) From: Danial Thom To: Robert Watson , freebsd-performance@freebsd.org In-Reply-To: <20060612155149.S24745@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Initial 6.1 questions X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: danial_thom@yahoo.com List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:58:02 -0000 --- Robert Watson 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? DT __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com