From owner-freebsd-hackers@FreeBSD.ORG Thu May 31 19:52:53 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 2D6F6106567B; Thu, 31 May 2012 19:52:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E45A38FC16; Thu, 31 May 2012 19:52:52 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2074269pbb.13 for ; Thu, 31 May 2012 12:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fiZQTaWCXfe1s88jC9b66KIJvRUsrDfGvj6I0P5YfEw=; b=GvCBqSZ5kmm8X1fLc8VeYhFw/ft2z9yJ7I/VmtOct5H/Aep6XksGrUVdY0qsNgsKuB k5Wb0kfsMfDJPMrt7rVEsvRN+Nd95NJU86uK2Djvl0zPeQC4k+J2s1viX3nREswG9n+Y RIXxJUHF+5uNB70dbLBse0RXptdPJvuGnnyCwuvZYI+AiXPzE86PjhIoP9ZvoSLglvOo wktpA1tJ9lJfdwmjrRFenwf0+S3qeZdQ41Nh0ZVx0Cx2HEqXIBOv4Sz7QhYleb6bMglJ cbsWC55uscrV1uGeXDDAIV+seR7Mz17+LlEkR3w42RnKulIUuBXe2hOzQu51xYxrqRKa IovQ== MIME-Version: 1.0 Received: by 10.68.223.167 with SMTP id qv7mr2638549pbc.127.1338493972375; Thu, 31 May 2012 12:52:52 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.203.2 with HTTP; Thu, 31 May 2012 12:52:52 -0700 (PDT) In-Reply-To: <201205311055.27648.jhb@freebsd.org> References: <201205301124.52597.jhb@freebsd.org> <201205311055.27648.jhb@freebsd.org> Date: Thu, 31 May 2012 12:52:52 -0700 X-Google-Sender-Auth: XDE-FPNiRuWondkw1CrpXvl6tds Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alexander Motin 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 19:52:53 -0000 On 31 May 2012 07:55, John Baldwin wrote: > On Wednesday, May 30, 2012 6:02:15 pm Adrian Chadd wrote: >> Hi, >> >> 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.) > > Why do you not expect that? =A0I would try, btw, just disabling powerd fo= r now > and leaving C2/C3 enabled to see if that makes a difference. I expected it because I didn't know what else is going on. Thanks to your braindumping in this thread, I now have a much better appreciation for the issues here. :-) > As to my first question, with powerd enabled and an otherwise idle machin= e, > powerd may very well be running your CPU at some rediculously low speed (= like > 100 Mhz) pretty much all the time. =A0Do you really think you could push = more > than 80 MBit with a 100 MHz CPU? This is with the power connected, so powerd seems to leave the CPU at full speed. I'll have to double-check. > Secondly, just having a lot of CPU isn't enough if you don't have it quic= kly. > Latency matters, too. =A0Take a look at your C2/C3 info like so: > > dev.cpu.0.cx_supported: C1/3 C2/59 C3/93 > > IIRC, the last number is the number of microseconds the CPU takes to resu= me > from an interrupt. =A0So, on this box (a Core i5), it can take 93 us afte= r an > interrupt occurs during C3 before the CPU will get around to executing th= e > first instruction. =A0It might be worse on your machine. Ok. I'll check the latency values when I'm back at home. The default bootup too is to use the ACPI idle routine, Even with powerd disabled and sleep limited to C1, I still see the TSC mismatch issues. I've modified my kernel to default to using spin at bootup. I'll see if this fixes the TSC mismatch when doing KTR traces. Thanks, Adrian