In fact, ACPI methods can execute concurrently -- constrained by the ACPI specification itself. The "big lock" is released before anything that will block for a significant amount of time, allowing other methods to run. Bob >-----Original Message----- >From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >owner@xxxxxxxxxxxxxxx] On Behalf Of Bjorn Helgaas >Sent: Tuesday, April 14, 2009 8:49 AM >To: Arjan van de Ven >Cc: Alan Jenkins; linux-acpi@xxxxxxxxxxxxxxx; linux-kernel; Kernel Testers >List; Pallipadi, Venkatesh >Subject: Re: [BISECTED] EEE PC hangs when booting off battery > >On Tuesday 14 April 2009 09:17:28 am Arjan van de Ven wrote: >> On Tue, 14 Apr 2009 08:59:01 -0600 >> Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: >> >> > I can't help with the real problem of why the asynchronous battery >> > init causes the hang. >> >> that got fixed already for the module case. > >But apparently still broken for the builtin case? I think Alan is >running pretty new bits -- he said "latest git" on April 11. > >> > But I do object to the magic makefile ordering change in that commit. >> > Nobody reading the makefile can tell why battery is down at the end, >> > and moving it apparently slows down boot significantly. >> >> for all cases I've seen it actually speeds it up, because the battery >> now runs concurrently with the disk probe. > >I understand; I just meant that if somebody moves it back where it >was, we'll mysteriously lose the speedup you got. Maybe a comment >in the makefile would be a short-term solution. > >> > So the >> > ordering change just feels like a band-aid that covers up a place >> > where ACPI could be improved. >> >> the reason for the move is that both the battery and other pieces take >> the big acpi lock; which defeats the parallelism. So the battery needs >> to happen at the end instead. > >Yep. But I don't think it's anything about the Linux battery driver >itself that makes it slow. I think it's more likely that some of the >ACPI methods it executes happen to be slow. And that could afflict >*any* driver, depending on the whim of a BIOS writer. > >My guess is that if we could run ACPI methods concurrently and avoid >that big lock, the ordering wouldn't matter. I know we probably can't >do that any time soon, but I think it's good to make the problem >visible at least with a "we need this magic order because ACPI doesn't >support concurrent method execution" sort of comment. > >Bjorn >-- >To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
