From owner-freebsd-performance@FreeBSD.ORG Wed Feb 6 20:07:50 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F00C16A476 for ; Wed, 6 Feb 2008 20:07:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C147213C4FA; Wed, 6 Feb 2008 20:07:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47AA1395.2090501@FreeBSD.org> Date: Wed, 06 Feb 2008 21:07:49 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Stefan Lambrev References: <4794E6CC.1050107@moneybookers.com> <47A0B023.5020401@moneybookers.com> <47A3074A.3040409@moneybookers.com> <47A72EAB.6070602@moneybookers.com> <20080204182945.GA49276@heff.fud.org.nz> <47A780C0.2060201@moneybookers.com> <47A799A6.3070502@moneybookers.com> <47A84751.8020109@moneybookers.com> <47A8D233.8020506@FreeBSD.org> <47A8DCD6.3060209@moneybookers.com> <47A8E1F1.4040309@FreeBSD.org> <47A98CDC.2090407@moneybookers.com> <47A993D0.1060901@FreeBSD.org> <47A99736.8060809@moneybookers.com> <47A99B16.6030305@FreeBSD.org> <47A9B636.3040509@moneybookers.com> In-Reply-To: <47A9B636.3040509@moneybookers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: network performance 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: Wed, 06 Feb 2008 20:07:50 -0000 Stefan Lambrev wrote: > Greetings, > > Kris Kennaway wrote: >> Yes, it is gone with 8.0. Disable the module builds because some of >> them like this one probably need compile fixes. If you need a subset >> of modules use MODULES_OVERRIDE=list (in /etc/make.conf) >> > Yes, kernel builds. > I'm still playing with it, but the first results shows that new kernel > can handle 800k incoming packets (well may be more but I have not enough > power right now to generate more packets). > It still answer only to 250K-260K. I guess I'm hitting the limitation of > syncache/syncookies ? Yes, it could be. You may need to tune the net.inet.tcp.syncache parameters to get better performance. That is good news though. > Anyway this netisr2 looks like huge improvement :) Actually I forgot to mention: you probably want to set net.isr2.direct=1. > I can't build kernel without option LOCK_PROFILING with your sources: > > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" > CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe > -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa > -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 > -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding > In file included from /usr/src/sys/netinet/ip_output.c:47: > /usr/src/sys/sys/rwlock.h:153:2: error: #error LOCK_DEBUG not defined, > include before > mkdep: compile failed > *** Error code 1 > > So I added #include , rebuild kernel and tested again w/o > LOCK_PROFILING, but results are the same. Thanks, I think I forgot to check in another fix. As you found though, LOCK_PROFILING does not have a large performance impact when compiled in but not active. > I'll use again hwpmc and LOCK_PROFILING to see what's going on. > And will try the same benchmark on quad core processor as now numbers of > cores/cpus matter :) That will certainly be interesting to test! Kris