From owner-freebsd-hackers@FreeBSD.ORG Thu May 31 15:42:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7C301065680; Thu, 31 May 2012 15:42:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D49028FC1C; Thu, 31 May 2012 15:42:22 +0000 (UTC) Received: by bkvi18 with SMTP id i18so1279292bkv.13 for ; Thu, 31 May 2012 08:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o5Jctvosda/ga2Odtt3Wkf/0CpHFJElqyfPQYGYp1Wo=; b=WSLv2ee2v+2yLvCA0uPCxvdBv7jwNQvhsaiTGC8KIi7iYfsyYngU5hvyNQkVitIakd 38gVaWVHhIcrbA21fU0nWB2wDdI6O9QjwNY4mvfn2ium7NA811hakBYSmhaClo+0iVDb /0lvIfEIXusdz3G2BaPvluHrYl2Z4+At6mjFNj5pwKZnyX6JUJSln6RbgyGaWl9kGhbs cny9CdPNF2yceUuLvoo59ieyhw6e6i4JqtwpALiNWS0uVSaYcsyXwUWL4y/76jaZZaDx /1J5tT0VTCb5TDQlWowvON6T+P4cSfTWtOaogxv3sexplwH03nD4+CsPGMotleAXAfBG Aumg== Received: by 10.204.148.79 with SMTP id o15mr1911147bkv.87.1338478941850; Thu, 31 May 2012 08:42:21 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id fw10sm3802511bkc.11.2012.05.31.08.42.19 (version=SSLv3 cipher=OTHER); Thu, 31 May 2012 08:42:20 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FC7915A.8080801@FreeBSD.org> Date: Thu, 31 May 2012 18:42:18 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Adrian Chadd References: <201205301124.52597.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: ULE/sched issues on stable/9 - why isn't preemption occuring? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:42:23 -0000 On 05/31/12 01:02, Adrian Chadd wrote: > I've re-run the test with powerd and sleep state stuff disabled - lo > and behold, UDP tests are now up around 240-250MBit, what I'd expect > for this 2 stream 11n device. > > So why is it that I lose roughly 80MBit of throughput with powerd and > C2/C3 enabled, when there's plenty of CPU going around? The NIC > certainly isn't going to sleep (I've not even added that code.) I've seen penalties from both of them myself on latency-sensitive single-threaded disk benchmark: 17K IOPS instead of 30K IOPS without. Problem with powerd was that CPU load during the test was below powerd idle threshold and it decided to drop frequency, that proportionally increased I/O handling latency. powerd can't know that while average CPU load is now, the request handling latency is critical for the test. About C-states, I've noticed on my tests on Core2Duo system that while ACPI reports equal exit latency for C1 and C2 states of 1us there, they are not really equal -- C2 exit is measurably slower. On newer generations of systems (Core i) I've never seen C2 latency reported as 1us, but instead it has much higher values. Having real big value there system should automatically avoid entering those states under the high interrupt rates to not get penalties. But that is all about latency-sensitive test. I am surprised to see such results for the network benchmarks. Handling packets in bursts should hide that latency. Unless you are loosing packets because of some overflows during these delays. -- Alexander Motin