Date: Thu, 19 Jul 2012 09:12:39 -0500 From: Eric van Gyzen <eric@vangyzen.net> To: Steve McCoy <smccoy@greatbaysoftware.com> Cc: Charles Owens <cowens@greatbaysoftware.com>, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: mfi(4) IO performance regression, post 8.1 Message-ID: <500815D7.4030407@vangyzen.net> 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
On 07/17/12 15:39, Steve McCoy wrote: > On 7/13/12 9:39 AM, John Baldwin wrote: >> On Thursday, July 12, 2012 11:47:28 pm Steve McCoy wrote: >>> On 7/12/12 4:34 PM, Steve McCoy wrote: >>>>>> John Baldwin wrote: >>>>> >>>>> Barring that, can you do a binary search of kernels from stable/8 >>>>> between 8.1 >>>>> and 8.2 on an 8.1 world to see which commit caused the change in write >>>>> performance? >>>>> >>>> >>>> Hi John, I'm working with Charles to narrow this down. >>>> >>>> Looks like revision 212229 is the culprit, or at least around the same >>>> time to it, if this change isn't what slowed things down. The change to >>>> sys/kern/vfs_bio.c modifies some synchronization in dev_strategy(): >>>> >>> >>> Actually, hold that thought. I had a hunch that I wasn't thorough >>> enough, so I decided to try 212228 — the performance is the same as with >>> 212229, so vfs_bio seems to be out of the picture. I'm going to binary >>> search between 209459 and 212229, and see what I find. >> >> Ok. Please let me know what you find. Thanks! >> > > 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! You might simply try a different idle function. See these sysctls: machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?500815D7.4030407>