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
