From owner-freebsd-performance@FreeBSD.ORG Mon Jun 12 20:02:52 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 0C9C116A418 for ; Mon, 12 Jun 2006 20:02:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3A4443D46 for ; Mon, 12 Jun 2006 20:02:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 36CE346C72; Mon, 12 Jun 2006 16:02:51 -0400 (EDT) Date: Mon, 12 Jun 2006 21:02:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danial Thom In-Reply-To: <20060612195754.72452.qmail@web33306.mail.mud.yahoo.com> Message-ID: <20060612210054.S26068@fledge.watson.org> References: <20060612195754.72452.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@freebsd.org Subject: Re: Initial 6.1 questions X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 20:02:52 -0000 On Mon, 12 Jun 2006, Danial Thom wrote: >> 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? No, shouldn't do. I wouldn't go below 100 though, as things like process statistics, involuntary context switches, etc, are all affected. >> 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? The above comments only refer to traffic being sent over if_loop interfaces or certain other deferred work scenarios. Basically, defering of work to the netisr from a user thread rather than an interrupt thread results in a premature context switch. Robert N M Watson Computer Laboratory Universty of Cambridge