Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jul 2012 22:39:50 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Charles Owens <cowens@greatbaysoftware.com>, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org>, Steve McCoy <smccoy@greatbaysoftware.com>
Subject:   Re: mfi(4) IO performance regression, post 8.1
Message-ID:  <5009B406.10706@FreeBSD.org>
In-Reply-To: <50095F38.4040204@FreeBSD.org>
References:  <4FDABA0B.5030702@greatbaysoftware.com> <4FFF34BA.9030002@greatbaysoftware.com> <4FFF9A50.40006@greatbaysoftware.com> <201207130939.54311.jhb@freebsd.org> <5005CD83.306@greatbaysoftware.com> <CAJ-VmomHhDrWfqw4aNKMQ-RWvJQ4uyRYdPcMzp61S3AQ%2BOhwqQ@mail.gmail.com> <50095F38.4040204@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <smccoy@greatbaysoftware.com> 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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5009B406.10706>