From owner-freebsd-stable@FreeBSD.ORG Fri Jul 20 19:39:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1A371065677; Fri, 20 Jul 2012 19:39:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E026F8FC0C; Fri, 20 Jul 2012 19:39:55 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3905047wgb.31 for ; Fri, 20 Jul 2012 12:39:54 -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=XogBPNzTH0mmUa58o/xIaYz+5YpjBMla6VpqEjaSBjc=; b=wDjqi9+g/DANjRIPX6C8qP3qWc9LR/lCveLt6G/axyNZ10mQ5szPqak70wjInt1/2U Z+TKlQkVLdt5FqNF3uQsAdN8EKhPOmjnneMVVYz5Lkut4d7Qg6kWvjnK/iLLE1fMenx4 +8gyWkHTIKYuaUw8b5ObwLT+6SWR10d2XrSMR2b0U5moYvIfqecZOkuGe1p2ZSEIOSfc VXTdyO6vquoV0iP8YBwLAJnvmjsX88VWdZqC2/zgT95m8uJDBo7/qT7UzFWGfKDzx0b/ SkRSA1LYc011smWfiVLhD62c5KqhwfX04I34gEY6duZmOP06GKS+zBpbyen80bqih02f 4kQw== Received: by 10.216.95.74 with SMTP id o52mr4082547wef.123.1342813194741; Fri, 20 Jul 2012 12:39:54 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id cl8sm46570000wib.10.2012.07.20.12.39.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jul 2012 12:39:53 -0700 (PDT) Sender: Alexander Motin Message-ID: <5009B406.10706@FreeBSD.org> Date: Fri, 20 Jul 2012 22:39:50 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <4FDABA0B.5030702@greatbaysoftware.com> <4FFF34BA.9030002@greatbaysoftware.com> <4FFF9A50.40006@greatbaysoftware.com> <201207130939.54311.jhb@freebsd.org> <5005CD83.306@greatbaysoftware.com> <50095F38.4040204@FreeBSD.org> In-Reply-To: <50095F38.4040204@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Charles Owens , freebsd-stable@freebsd.org, John Baldwin , Steve McCoy Subject: Re: mfi(4) IO performance regression, post 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 19:39:57 -0000 On 20.07.2012 16:38, Alexander Motin wrote: > On 19.07.2012 18:28, Adrian Chadd wrote: >> Hm! A timer related bug? >> >> I'll CC mav@ on this, as it was his commit (and work in his general >> area.) >> >> I wonder what's going on - is it something to do with the two ACPI >> calls inserted there, or is it something to do with the change in >> event timer values? >> >> mav? Any ideas? > > I can just agree with earlier made guess that for some reason ACPI timer > on that system is very slow. Unless user explicitly enabled deeper > C-states, values returned by the timer are not really used for anything, > so there is just no place for other bug. > > When doing this change I was expecting that it may have cost, but on > most systems that cost makes effect only during high interrupt rates, > where it is covered by automatic fallback to using faster MWAIT as idle > method. Unluckily, that code still was not merged to 8-STABLE (only 9). > I will recheck is there problem to merge it now. I've just merged that to 8-STABLE at r238658. Testers are welcome. > Manual switching to MWAIT via sysctl is correct workaround for this > situation. It may give slightly higher power consumption, but for this > workload with many interrupts probably the best possible performance. > >> On 17 July 2012 13:39, Steve McCoy wrote: >> >>> Alright, I've finally narrowed it down to r209897, which only affects >>> acpi_cpu_idle(): >>> >>> --- stable/8/sys/dev/acpica/acpi_cpu.c 2010/06/23 17:04:42 209471 >>> +++ stable/8/sys/dev/acpica/acpi_cpu.c 2010/07/11 11:58:46 209897 >>> @@ -930,12 +930,16 @@ >>> >>> /* >>> * Execute HLT (or equivalent) and wait for an interrupt. We >>> can't >>> - * calculate the time spent in C1 since the place we wake up is an >>> - * ISR. Assume we slept half of quantum and return. >>> + * precisely calculate the time spent in C1 since the place we >>> wake up >>> + * is an ISR. Assume we slept no more then half of quantum. >>> */ >>> if (cx_next->type == ACPI_STATE_C1) { >>> - sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + 500000 / hz) / 4; >>> + AcpiHwRead(&start_time, &AcpiGbl_FADT.XPmTimerBlock); >>> acpi_cpu_c1(); >>> + AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); >>> + end_time = acpi_TimerDelta(end_time, start_time); >>> + sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + >>> + min(PM_USEC(end_time), 500000 / hz)) / 4; >>> return; >>> } >>> >>> My current guess is that AcpiHwRead() is a problem on our hardware. >>> It's an >>> isolated change and, to my desperate eyes, the commit message implies >>> that >>> it isn't critical — Do you think we could buy ourselves some time by >>> pulling >>> it out of our version of the kernel? Or is this essential for >>> correctness? >>> Any thoughts are appreciated, thanks! > > -- Alexander Motin