acpi_idle: Very idle Core i7 machine never enters C3
in [Kernel]
|
Prev: linux-next: manual merge of the drm tree with Linus' tree
Next: Can you include a new git tree in linux-next, the staging-next tree?
From: Len Brown on 30 Apr 2010 13:40 Philip, Jeff, Please open up a bugzilla.kernel.org report and attach the output from acpidump from your machines. I am hopeful that the "right thin to do" is to not look at bm-status and that perhaps there is a bug where we are looking at it "by mistake". However, it is important that the system be operating properly when it indeed using c6 as it does with that 1 line patch earlier in this thread. So if that patch causes abnormal operation, please let me know. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 30 Apr 2010 13:50 On Fri, Apr 30, 2010 at 12:25:44PM -0400, Len Brown wrote: > I am hopeful that the "right thin to do" is to not look at bm-status > and that perhaps there is a bug where we are looking at it > "by mistake". https://patchwork.kernel.org/patch/58962/ - it seems to be a win. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Philip Langdale on 30 Apr 2010 14:40 On Fri, 30 Apr 2010 18:44:47 +0100, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Fri, Apr 30, 2010 at 12:25:44PM -0400, Len Brown wrote: > >> I am hopeful that the "right thin to do" is to not look at bm-status >> and that perhaps there is a bug where we are looking at it >> "by mistake". > > https://patchwork.kernel.org/patch/58962/ - it seems to be a win. Indeed. This patch does solve the C6 problem. I'm not in a position to speak about whether there's any undesirable I/O latency, but it passes the basic sanity check. I have filed https://bugzilla.kernel.org/show_bug.cgi?id=15886 with my acpi dump - assuming that's still useful. --phil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Len Brown on 25 May 2010 01:50 > >> I am hopeful that the "right thing to do" is to not look at bm-status > >> and that perhaps there is a bug where we are looking at it > >> "by mistake". > > > > https://patchwork.kernel.org/patch/58962/ - it seems to be a win. > > Indeed. This patch does solve the C6 problem. I'm not in a position to > speak about whether there's any undesirable I/O latency, but it > passes the basic sanity check. > > I have filed https://bugzilla.kernel.org/show_bug.cgi?id=15886 with > my acpi dump - assuming that's still useful. Luming's patch above basically deletes acpi_idle_bm_check() -- the BM_STS check -- from the C3 path on all Intel SMP boxes. This is effectively the same as my test patch https://patchwork.kernel.org/patch/77370/ that made acpi_idle_bm_check() do nothing. I'm told by the hardware guys that BM_STS is _not_ always a NOP, and so we're not supposed to simply ignore it on C3 -- though it should be extremely rare that we see it set. If it is ever set, it should go on and off depending on activity on some latency sensitive device, like out on the LPC. It may be possible for the BIOS writer to configure the chipset so that BM_STS is enabled always, presumably to accomodate some latency sensitve device -- or maybe by mistake. (is it observed to be set always on your systems, or does it ever change its value?) The logic in Luming's patch doesn't make sense to me. bm_check and bm_control are related to C3 need to flush the cache or ability to invoke ARB_DIS. They are not directly related to BM_STS -- which is a bit that tells us if there has recently been bus master activity of a type that would break us out of C3. -Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yu, Luming on 25 May 2010 02:10
> -----Original Message----- > From: Len Brown [mailto:lenb(a)kernel.org] > Sent: Tuesday, May 25, 2010 1:43 PM > To: Philip Langdale > Cc: Matthew Garrett; Jeff Garrett; Andi Kleen; Linux Kernel Mailing > List; linux-acpi(a)vger.kernel.org; Yu, Luming; venki(a)google.com > Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3 > > > >> I am hopeful that the "right thing to do" is to not look at bm- > status > > >> and that perhaps there is a bug where we are looking at it > > >> "by mistake". > > > > > > https://patchwork.kernel.org/patch/58962/ - it seems to be a win. > > > > Indeed. This patch does solve the C6 problem. I'm not in a position > to > > speak about whether there's any undesirable I/O latency, but it > > passes the basic sanity check. > > > > I have filed https://bugzilla.kernel.org/show_bug.cgi?id=15886 with > > my acpi dump - assuming that's still useful. > > Luming's patch above basically deletes acpi_idle_bm_check() -- > the BM_STS check -- from the C3 path on all Intel SMP boxes. > This is effectively the same as my test patch > https://patchwork.kernel.org/patch/77370/ > that made acpi_idle_bm_check() do nothing. > > I'm told by the hardware guys that BM_STS is _not_ always > a NOP, and so we're not supposed to simply ignore it on C3 -- > though it should be extremely rare that we see it set. On some platforms like NHM-EX, I was told that it's a NOP, But I might be given wrong information at that time when I wrote that patch. IIRC, acpi spec just say it's optional.. Thanks, Luming -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |