7:20 a.m.
On Thu, May 7, 2020 at 9:43 AM Rafael J. Wysocki
<rafael.j.wysocki(a)intel.com> wrote:
On 5/7/2020 1:39 AM, Dan Williams wrote:
> Recently a performance problem was reported for a process invoking a
> non-trival ASL program. The method call in this case ends up
> repetitively triggering a call path like:
>
> acpi_ex_store
> acpi_ex_store_object_to_node
> acpi_ex_write_data_to_field
> acpi_ex_insert_into_field
> acpi_ex_write_with_update_rule
> acpi_ex_field_datum_io
> acpi_ex_access_region
> acpi_ev_address_space_dispatch
> acpi_ex_system_memory_space_handler
> acpi_os_map_cleanup.part.14
> _synchronize_rcu_expedited.constprop.89
> schedule
>
> The end result of frequent synchronize_rcu_expedited() invocation is
> tiny sub-millisecond spurts of execution where the scheduler freely
> migrates this apparently sleepy task. The overhead of frequent scheduler
> invocation multiplies the execution time by a factor of 2-3X.
>
> For example, performance improves from 16 minutes to 7 minutes for a
> firmware update procedure across 24 devices.
>
> Perhaps the rcu usage was intended to allow for not taking a sleeping
> lock in the acpi_os_{read,write}_memory() path which ostensibly could be
> called from an APEI NMI error interrupt? Neither rcu_read_lock() nor
> ioremap() are interrupt safe, so add a WARN_ONCE() to validate that rcu
> was not serving as a mechanism to avoid direct calls to ioremap(). Even
> the original implementation had a spin_lock_irqsave(), but that is not
> NMI safe.
>
> APEI itself already has some concept of avoiding ioremap() from
> interrupt context (see erst_exec_move_data()), if the new warning
> triggers it means that APEI either needs more instrumentation like that
> to pre-emptively fail, or more infrastructure to arrange for pre-mapping
> the resources it needs in NMI context.
>
> Cc: <stable(a)vger.kernel.org>
> Fixes: 620242ae8c3d ("ACPI: Maintain a list of ACPI memory mapped I/O
remappings")
> Cc: Len Brown <lenb(a)kernel.org>
> Cc: Borislav Petkov <bp(a)alien8.de>
> Cc: Ira Weiny <ira.weiny(a)intel.com>
> Cc: James Morse <james.morse(a)arm.com>
> Cc: Erik Kaneda <erik.kaneda(a)intel.com>
> Cc: Myron Stowe <myron.stowe(a)redhat.com>
> Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
> Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
linux-acpi is kind of relevant for this too, so please CC it.
Whoops, my bad. Will resend with some of Andy's cleanup suggestions.