Date: Thu, 19 Jul 2012 08:28:32 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Steve McCoy <smccoy@greatbaysoftware.com> Cc: Charles Owens <cowens@greatbaysoftware.com>, Alexander Motin <mav@freebsd.org>, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: mfi(4) IO performance regression, post 8.1 Message-ID: <CAJ-VmomHhDrWfqw4aNKMQ-RWvJQ4uyRYdPcMzp61S3AQ%2BOhwqQ@mail.gmail.com> In-Reply-To: <5005CD83.306@greatbaysoftware.com> References: <4FDABA0B.5030702@greatbaysoftware.com> <4FFF34BA.9030002@greatbaysoftware.com> <4FFF9A50.40006@greatbaysoftware.com> <201207130939.54311.jhb@freebsd.org> <5005CD83.306@greatbaysoftware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Adrian
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 =3D=3D ACPI_STATE_C1) {
> - sc->cpu_prev_sleep =3D (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 =3D acpi_TimerDelta(end_time, start_time);
> + sc->cpu_prev_sleep =3D (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 tha=
t
> it isn't critical =97 Do you think we could buy ourselves some time by pu=
lling
> it out of our version of the kernel? Or is this essential for correctness=
?
> Any thoughts are appreciated, thanks!
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomHhDrWfqw4aNKMQ-RWvJQ4uyRYdPcMzp61S3AQ%2BOhwqQ>