From owner-freebsd-current@FreeBSD.ORG Tue Nov 5 20:14:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BE602BB; Tue, 5 Nov 2013 20:14:24 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F60A2373; Tue, 5 Nov 2013 20:14:24 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id gq1so8993674obb.4 for ; Tue, 05 Nov 2013 12:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LuYxKo89D7ZO71DuOL/DL9jwBJsmXVemoucOpgGFNWs=; b=QV8quOBfW9KsNcBJJj4WFLch8m8Vd2gz+vh/wyre+5RiYevct2S5hFmx8k54lEgI7N a5RB5JA/r5AaFdJCwDV2Pr0p3HLP9Xbopex+TYj66fB6qcZNZC7bbs6bg9PosnKSU7O+ 00Z7hQPanR0uhas6XfiXozbRpPGk2J+KKaF6BG3Xfwbrf5vMrAhvfWx9eHLPks6a1AU6 IJvhgj2BX3aXIC+witqwJqFZbcotawFaxY0egMYpeo9DC/zdSyU0GrQzRQLKjcKgwo3k XdanVq0TqUVHZQscHiX3XpPi1mY+NRXEO610ATlOwSp3Pg7yva+5+62sDb69fTKyqWht Ptdw== MIME-Version: 1.0 X-Received: by 10.182.204.41 with SMTP id kv9mr22242obc.78.1383682462827; Tue, 05 Nov 2013 12:14:22 -0800 (PST) Received: by 10.182.80.7 with HTTP; Tue, 5 Nov 2013 12:14:22 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 21:14:22 +0100 Message-ID: Subject: Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer From: Oliver Pinter To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , Alexander Motin , FreeBSD Stable Mailing List , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:14:24 -0000 hmm, and seems like, the bottleneck are not in geom or cam, but in em driver or in networking stack the scenario is: A machine: dd if=/dev/ada1 bs=1M | nc -l 9999 B machine: nc IP 9999 | dd of=/dev/null bs=1M hmm, when dd-ing from /dev/zero and switch back to idletick to 0, then the performance of network dropped from 113MByte/s to 70+/-15 MByte/s machdep.idle_mwait=1/0 has no effect machdep.idle=htl has no effect On 11/5/13, Oliver Pinter wrote: > dmesg corrected > > On 11/5/13, Oliver Pinter wrote: >> On 11/5/13, Adrian Chadd wrote: >>> Ok, so it's only hitting C1. It's not going into C2. >>> >>> Is this a dual core CPU with hyperthreading enabled, or a quad core CPU? >> >> quad core, i5-4670 >> >>> >>> How about changing the idle loop from acpi to hlt, see if that fixes >>> things? (Without tweaking the event timer logic.) >> >> Now, after reboot, the problem has gone. The other symptom are: on vt >> switching is laggish, and switching the num lock state delayed >> ~0.5sec. >> >> This are reproducible ~ every 10-15th boot. >> >>> >>> I'm worried that what you're seeing here are missed interrupts or >>> interrupts that aren't immediately causing the driver thread to be >>> scheduled (and thus things enter HLT until the next interrupt.) I had >>> to deal with this crap on MIPS for quite some time. >>> >>> sysctl machdep.idle=hlt >>> >>> >>> >>> -adrian >>> >>> >>> On 5 November 2013 09:25, Oliver Pinter wrote: >>>> op@perpetua ~> sysctl dev.cpu >>>> dev.cpu.0.%desc: ACPI CPU >>>> dev.cpu.0.%driver: cpu >>>> dev.cpu.0.%location: handle=\_PR_.CPU0 >>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.0.%parent: acpi0 >>>> dev.cpu.0.coretemp.delta: 59 >>>> dev.cpu.0.coretemp.resolution: 1 >>>> dev.cpu.0.coretemp.tjmax: 100.0C >>>> dev.cpu.0.coretemp.throttle_log: 0 >>>> dev.cpu.0.temperature: 41.0C >>>> dev.cpu.0.freq_levels: 3401/84000 3400/84000 3200/77169 3000/70587 >>>> 2800/64262 2700/61182 2500/55201 2300/49464 2100/43946 1900/38654 >>>> 1700/34277 1500/29407 1400/27053 1225/23671 1200/22509 1050/19695 >>>> 1000/18167 875/15896 800/14031 700/12277 600/10523 500/8769 400/7015 >>>> 300/5261 200/3507 100/1753 >>>> dev.cpu.0.cx_supported: C1/1/1 C2/2/67 >>>> dev.cpu.0.cx_lowest: C1 >>>> dev.cpu.0.cx_usage: 100.00% 0.00% last 812us >>>> dev.cpu.1.%desc: ACPI CPU >>>> dev.cpu.1.%driver: cpu >>>> dev.cpu.1.%location: handle=\_PR_.CPU1 >>>> dev.cpu.1.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.1.%parent: acpi0 >>>> dev.cpu.1.coretemp.delta: 56 >>>> dev.cpu.1.coretemp.resolution: 1 >>>> dev.cpu.1.coretemp.tjmax: 100.0C >>>> dev.cpu.1.coretemp.throttle_log: 0 >>>> dev.cpu.1.temperature: 44.0C >>>> dev.cpu.1.cx_supported: C1/1/1 C2/2/67 >>>> dev.cpu.1.cx_lowest: C1 >>>> dev.cpu.1.cx_usage: 100.00% 0.00% last 1348us >>>> dev.cpu.2.%desc: ACPI CPU >>>> dev.cpu.2.%driver: cpu >>>> dev.cpu.2.%location: handle=\_PR_.CPU2 >>>> dev.cpu.2.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.2.%parent: acpi0 >>>> dev.cpu.2.coretemp.delta: 61 >>>> dev.cpu.2.coretemp.resolution: 1 >>>> dev.cpu.2.coretemp.tjmax: 100.0C >>>> dev.cpu.2.coretemp.throttle_log: 0 >>>> dev.cpu.2.temperature: 39.0C >>>> dev.cpu.2.cx_supported: C1/1/1 C2/2/67 >>>> dev.cpu.2.cx_lowest: C1 >>>> dev.cpu.2.cx_usage: 100.00% 0.00% last 845us >>>> dev.cpu.3.%desc: ACPI CPU >>>> dev.cpu.3.%driver: cpu >>>> dev.cpu.3.%location: handle=\_PR_.CPU3 >>>> dev.cpu.3.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.3.%parent: acpi0 >>>> dev.cpu.3.coretemp.delta: 62 >>>> dev.cpu.3.coretemp.resolution: 1 >>>> dev.cpu.3.coretemp.tjmax: 100.0C >>>> dev.cpu.3.coretemp.throttle_log: 0 >>>> dev.cpu.3.temperature: 38.0C >>>> dev.cpu.3.cx_supported: C1/1/1 C2/2/67 >>>> dev.cpu.3.cx_lowest: C1 >>>> dev.cpu.3.cx_usage: 100.00% 0.00% last 1609us >>>> >>>> On 11/5/13, Adrian Chadd wrote: >>>>> Hi! >>>>> >>>>> Can you do 'sysctl dev.cpu' please? I'd like to see what sleep >>>>> state(s) your CPU is entering. >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> -adrian >>>>> >>>>> >>>>> On 5 November 2013 06:07, Oliver Pinter wrote: >>>>>> Hi all! >>>>>> >>>>>> The machine is a Haswell machine, the disc performance was very poor >>>>>> (20-30MByte/sec). >>>>>> When I change the kern.eventtimer.idletick from 0 to 1, the normal >>>>>> performance restored back to normal (70-90MByte/sec). >>>>>> >>>>>> The default eventtimer was LAPIC. >>>>>> >>>>>> On other machine Q9300, this was fully reproducible. >>>>>> _______________________________________________ >>>>>> freebsd-current@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-current-unsubscribe@freebsd.org" >>>>> >>> >> >