From owner-freebsd-stable@FreeBSD.ORG Fri Jul 20 13:38:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AF82106564A; Fri, 20 Jul 2012 13:38:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B89C28FC18; Fri, 20 Jul 2012 13:38:12 +0000 (UTC) Received: by weyx56 with SMTP id x56so3191326wey.13 for ; Fri, 20 Jul 2012 06:38:05 -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=sAAvp27hMKsXJEA0+K2ikRDFW7cCQFMap3ZFg2THM9s=; b=JzvZJd3Kf8WK+Sbk6mPGqcg3XcXls5DtB+9dR2n2qytl+53cQdiKEygHs6wWmvlMy2 PTNl8jzWqqLuVn2NB9cH6FZL8GIdd38F/KhB86XTyho+0qsXeXDNUFr7mxT3hl7D1t+h 1fi+LWnh7bmo8cY/ZFOtzFfD/oiVw/kaHeC3Sh4ArZbRBYNFaXGbg6wHw35gmGNQYSz+ Wlv0JuJGDtCIPpn4yr0p8pRTm1FoiJhcbMpsJkYV2Yxfm4urGp/j46BOEyUHFC2yRZP4 juZpPxQ2SQITtJWTq0W/VPYz4VNDxvZgV3d2JvWTzuUSuW57kIXjaPV2wVhIVA8yaYEt Is1w== Received: by 10.216.154.69 with SMTP id g47mr3932251wek.171.1342791485651; Fri, 20 Jul 2012 06:38:05 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id bc2sm15139263wib.0.2012.07.20.06.38.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jul 2012 06:38:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <50095F38.4040204@FreeBSD.org> Date: Fri, 20 Jul 2012 16:38:00 +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> In-Reply-To: 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 13:38:13 -0000 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. 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