Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp2261850ybg; Fri, 5 Jun 2020 09:26:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtQRwwwYQBM3npodQChToMJjwC9jSjUTIOv4R2x3nENzICnyquMiytMVpxLriQ/AGyf2uj X-Received: by 2002:a17:906:6453:: with SMTP id l19mr517825ejn.262.1591374383190; Fri, 05 Jun 2020 09:26:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591374383; cv=none; d=google.com; s=arc-20160816; b=YGVcxVEwZ+rvlikbFCW65Pf8LZYE2ouKbHp3TnX4TxVWcShuVkPkqy+niEur+e1+mR yfk5gNG/kR2jzyalCcJL/aJB/RfWjAvqTcf8rTEQ5efM/v2/ZOJ/Hehmp2DR9q2p7ktH r0LhZz5zD0eTwzba3j5wIewm00PR6hZqpidwzB9L7L15TbZOK0eGwp5diRSTJ5ttLch+ 5t5/2g1FxDPyt5cYTer/QbTAz4R8vxRy83F9//KmC2A+p4ergoOuV0zobaWGfklkXHb4 4oQ58X4olyH1J6c6T8u74+fjM60lMYzwpkfBiAmAj5u5VDWg8AspfS+vFxNY5x5DOAOE xLJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=tNm/MEsuRiThlj0w2Ep6hniygV5tFbfb9SR7Z3GLj9Y=; b=S+LfbnpbH81sh1EdKdm+GR3d8TtGQBRJ0D2/GM2TcRYUL0wDoWOEI4oMboSIOyN00L YvhHgFSnq2k+O82Fq0rmBXztYolYii7zQjOO0n9OEXZtUS8I7pLEpI8ngUZWSvVs4CDZ 4qdUlko3wpY3/zdeYXVHTYKaBSKX9sqPdGxeX8+PDtqR9z0PWEMSWcn3uYAIQf/mLTRg RMCk3f+2B9CbZQrV0ICCuq/iCzuWJ+Nsa4fqRk5+PkHH2wSmP1lfio5ykVNZdPCTFjqa 4v2ZPTG3GoCKsdtEvWBSACxGn0wIDuA7WnzMlYtfRgvHjQihAyc0gzbK53wBa8FAm0H6 21YQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l12si3426202ejn.435.2020.06.05.09.25.59; Fri, 05 Jun 2020 09:26:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726837AbgFEQVn (ORCPT + 99 others); Fri, 5 Jun 2020 12:21:43 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:34548 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726316AbgFEQVm (ORCPT ); Fri, 5 Jun 2020 12:21:42 -0400 Received: by mail-ot1-f65.google.com with SMTP id b18so8061249oti.1; Fri, 05 Jun 2020 09:21:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tNm/MEsuRiThlj0w2Ep6hniygV5tFbfb9SR7Z3GLj9Y=; b=YbkqS2xAQNP8YNDMayOSoXFruFdNzU6pLFsUOiZKSdsZZL3FM+8Wqb6AAeGLdsmALy 1PicxwCxQIF+e7CJMPqTAKkVZySs+wchMe6cppRL94vAUOEF9+xUmOgqEWxzEKbJCeOv wP0g1h2BlTcQe/3vPYZ8+AM25UX8VsPCCKBTgbqvcUwzzyC5cgwb8rJoWyaW3KzGR+Ir gy5Jbe9YbjRfTm5q4NVKXytBdxK9gqQtRNXEGsZu/6/u677XXIc7jjxQH+6OKIgFXRc8 6cdA/Ib/FFou+s4u7/PvCq6iEH5oUlBTEGB9bv/OKM2lFGGuEn98bWqhKvHydC2QUOAF k0MQ== X-Gm-Message-State: AOAM532ZOfGX0J0IYOGZlVy7UJFUHXP51uO8WoBGkzESzkylvHplMCVo rqv0i064/mgK78sm/E5rkhASMb7eFpLysByHxeI= X-Received: by 2002:a05:6830:20d1:: with SMTP id z17mr7872068otq.167.1591374101775; Fri, 05 Jun 2020 09:21:41 -0700 (PDT) MIME-Version: 1.0 References: <158889473309.2292982.18007035454673387731.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Fri, 5 Jun 2020 18:21:30 +0200 Message-ID: Subject: Re: [PATCH v2] ACPI: Drop rcu usage for MMIO mappings To: Dan Williams Cc: "Rafael J. Wysocki" , Rafael Wysocki , Stable , Len Brown , Borislav Petkov , Ira Weiny , James Morse , Erik Kaneda , Myron Stowe , "Rafael J. Wysocki" , Andy Shevchenko , Linux Kernel Mailing List , ACPI Devel Maling List , "linux-nvdimm@lists.01.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 5, 2020 at 6:18 PM Dan Williams wrote: > > On Fri, Jun 5, 2020 at 6:32 AM Rafael J. Wysocki wrote: > > > > On Fri, May 8, 2020 at 1:55 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? > > > > Not really. > > > > acpi_os_{read|write}_memory() end up being called from non-NMI > > interrupt context via acpi_hw_{read|write}(), respectively, and quite > > obviously ioremap() cannot be run from there, but in those cases the > > mappings in question are there in the list already in all cases and so > > the ioremap() isn't used then. > > > > RCU is there to protect these users from walking the list while it is > > being updated. > > > > > 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(). > > > > But it would produce false-positives if the IRQ context was not NMI, > > wouldn't it? > > > > > Even the original implementation had a spin_lock_irqsave(), but that is not > > > NMI safe. > > > > Which is not a problem (see above). > > > > > 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. > > > > Well, I'm not sure about that. > > Right, this patch set is about 2-3 generations behind the architecture > of the fix we are discussing internally, you might mention that. Yes, sorry. > The fix we are looking at now is to pre-map operation regions in a > similar manner as the way APEI resources are pre-mapped. The > pre-mapping would arrange for synchronize_rcu_expedited() to be elided > on each dynamic mapping attempt. The other piece is to arrange for > operation-regions to be mapped at their full size at once rather than > a page at a time. However, if the RCU usage in ACPI OSL can be replaced with an rwlock, some of the ACPICA changes above may not be necessary anymore (even though some of them may still be worth making).