| Message ID | CAJvTdK=gJk3N+75G97QpXiTnw9FDJPQiuR66sGgyc6e_zcesHQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, Nov 29, 2017 at 7:06 AM, Len Brown <lenb@kernel.org> wrote: > Rafael, > > Per our discussion... > > As of Linux-4.14, acpi_pm_finish() takes over 1,000 ms on the Dell > XPS13. This routine accounts for 50% of the total resume time of this > machine. > > So I commented _WAK out of acpi_hw_legacy_wake(), and that 1000ms > became 2ms. (and the system also seemed to resume fine without _WAK, > though I didn't test it extensively) > > So I effectively pre-pended acpi_pm_finish() to acpi_pm_end() with the > hack patch below, and that seems to work fine. > > (Note that it seems that the relative ordering of enabling run-time > GPEs and invoking _WAK is already correct in acpi_hw_legacy_wake() -- > the GPEs are enabled first.) The ordering is correct, but the GPEs should be enabled before the SCI is enabled by resume_device_irqs(). Arguably, they may just be enabled as soon as the kernel gets control back as the SCI won't trigger anyway before resume_device_irqs(). > So the question becomes... How early does _WAK really need to be? On this system, apparently, it may go late in the resume path. There are systems on which moving it after the PCI resume introduced issues, which is why the default ordering is what it is IIRC (but that was bundled with the GPE stuff then, so there could be effects of that too). In any case, we may play with the ordering, but that's fragile. Or we can enable the EC polling just for the time of executing _WAK (which should avoid the thermal issues on Lenovo and similar). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- > owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Sent: Wednesday, November 29, 2017 10:35 PM > To: Len Brown <lenb@kernel.org> > Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; linux acpi <linux- > acpi@vger.kernel.org> > Subject: Re: Dell XPS13 9360 - 1,000ms acpi_pm_finish() > > On Wed, Nov 29, 2017 at 7:06 AM, Len Brown <lenb@kernel.org> wrote: > > Rafael, > > > > Per our discussion... > > > > As of Linux-4.14, acpi_pm_finish() takes over 1,000 ms on the Dell > > XPS13. This routine accounts for 50% of the total resume time of this > > machine. > > > > So I commented _WAK out of acpi_hw_legacy_wake(), and that 1000ms > > became 2ms. (and the system also seemed to resume fine without _WAK, > > though I didn't test it extensively) > > How long does acpi_pm_finish() take in 4.12 kernel? It's good to know how much the reverted EC busy_polling mechanism can improve on this case. Thanks, rui > > So I effectively pre-pended acpi_pm_finish() to acpi_pm_end() with the > > hack patch below, and that seems to work fine. > > > > (Note that it seems that the relative ordering of enabling run-time > > GPEs and invoking _WAK is already correct in acpi_hw_legacy_wake() -- > > the GPEs are enabled first.) > > The ordering is correct, but the GPEs should be enabled before the SCI is > enabled by resume_device_irqs(). Arguably, they may just be enabled as > soon as the kernel gets control back as the SCI won't trigger anyway before > resume_device_irqs(). > > > So the question becomes... How early does _WAK really need to be? > > On this system, apparently, it may go late in the resume path. There are > systems on which moving it after the PCI resume introduced issues, which is > why the default ordering is what it is IIRC (but that was bundled with the GPE > stuff then, so there could be effects of that too). > > In any case, we may play with the ordering, but that's fragile. Or we can > enable the EC polling just for the time of executing _WAK (which should > avoid the thermal issues on Lenovo and similar). > > Thanks, > Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the > body of a message to majordomo@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html
> How long does acpi_pm_finish() take in 4.12 kernel? > It's good to know how much the reverted EC busy_polling mechanism can improve on this case. 4.12.0 acpi_pm_finish() takes on the order of 40ms (it varies somewhat), which is about the same speed as when this hack patch is applied. This is compared to over 1,100ms in current 4.14. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index 8082871b409a..f25f1874cfaf 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -495,6 +495,8 @@ static void acpi_pm_start(u32 acpi_state) */ static void acpi_pm_end(void) { + printk("lenb: acpi_pm_finish from within acpi_pm_end\n"); + acpi_pm_finish(); acpi_turn_off_unused_power_resources(); acpi_scan_lock_release(); /* @@ -639,7 +641,6 @@ static const struct platform_suspend_ops acpi_suspend_ops = { .begin = acpi_suspend_begin, .prepare_late = acpi_pm_prepare, .enter = acpi_suspend_enter, - .wake = acpi_pm_finish, .end = acpi_pm_end, };