Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp2273491ybg; Fri, 5 Jun 2020 09:42:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOGi72y1qBbi+oPOCO1GmSZzqAfeGmx+UeDKhy8C6MJXBDNfmFRx1InPf1/fGT/JyoHEo1 X-Received: by 2002:a05:6402:c09:: with SMTP id co9mr9784410edb.238.1591375373514; Fri, 05 Jun 2020 09:42:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591375373; cv=none; d=google.com; s=arc-20160816; b=obKKDZDxSYXJ9WhTGFiHqk2B10wTIsQLXJkNrmaT2hMp6wY58FoMXvv508iT77Uh8G Vvz895HogaimXm0rBL2+Keng1/NQrua+LTBPcK/85RghGU/vSie8DJ122Z+IpD0FLrmH Fq9vpAdrE5TUgvhwMDdcUh7cXKq6BXpNB7+9jl74Xudy41LLl1sfwWBmo1SCO3UGuGf+ KIoMZ753iI+eNNiyq4pKpK7JNSPRyhjWY5QqTb+7K4qU6cJi9a8HaTSHsAC3dAK9u4Wp xBhUGBMIl1UDkozez7ImQOl5e1RDlSv5PcHBoQdmF4aUvzOPirTjgaXdApsGwS59w1Cn sTSQ== 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:dkim-signature; bh=8MiHJvWvFUN4W4TOaBTTRVwH9Kbcz3EtLSrutNpEo/8=; b=iZND7hoJXJmtjuumWP75rWclpDQ08gXOzM1S0AC1fyo0Vca+5xNZXxEwxtY3VJz6Dq Djsv+wiajoj4ceW8kTLfUHhi2xQqMkuykK+K6Zdr8V63QWo3wD2+urRLAqolinrYMQ1I NofoBLTZJvqvZMo+RHMYe1NSzPn6ZZNFhsdeLUwNqnel/nY9Fx5Es2PPxi3GoQfOjwpA lpuuz4Qqa5Ef0gGcumThcJ6sYhigsX3FX64h+pyL3JSqmwCt0tPwH7Wkss1/b1vv7JoA AQtAmixJ3Pg6ic/xKZxH1S0bjeX75537mo+EynvQehoCSUB+DyLopkqv8rFHu/VzRLEp YPxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=BXGx739N; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nh7si3933425ejb.155.2020.06.05.09.42.30; Fri, 05 Jun 2020 09:42:53 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=BXGx739N; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726805AbgFEQj4 (ORCPT + 99 others); Fri, 5 Jun 2020 12:39:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725961AbgFEQjz (ORCPT ); Fri, 5 Jun 2020 12:39:55 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23A34C08C5C2 for ; Fri, 5 Jun 2020 09:39:55 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id a25so10805782ejg.5 for ; Fri, 05 Jun 2020 09:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8MiHJvWvFUN4W4TOaBTTRVwH9Kbcz3EtLSrutNpEo/8=; b=BXGx739NHMzDG5jF4pX2SjGcZdBMtypWsjdXc+T5TXcMRY3QFLn1zVYTB10ArVqHfw bS2lJVfCpuTD82oSoAPn3j92VWPnGK3U9NUDm8MQimf3XMKwYy5kLcX07pC1YGpVXB2O 3gP+9IYgz88+xJpYfAzaurF+CZ8yPzls/rjK0WfZtXiZKUXRZsqhDHr4qc11YmqpXt9e r86XRpvXT+Cy7gLPk8Rype/AN669h2aux8SKpgTvrVFDhanzHQcIcspCONHUC6/YyZs1 5ZPK/WfUFfhDs5cz5AFCES84sqyqXKNvoU5i+bNAsSbPuv0mImc46an+0ZEFKox19Ymn uSsA== 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=8MiHJvWvFUN4W4TOaBTTRVwH9Kbcz3EtLSrutNpEo/8=; b=kxM94sVbMCD4n3FQSSi0qj09ifIJwHl4LOZmSdgow+Q2beaiAg5YHAr17ISszMrXCl MByYaGMaz99zOjn3MWr5EDlPjRi+be8xb+tO2j1cAh3oFvrNhh5fIZ25zsaXVsR+ui59 ipESXeZsHgRBalzqm/xwfM5MDOfsrvUwUD9PM9J68j4yC0fR8JRGiLR+QcGbubIVdXGC T2p97EVdKAL9ea+3faQCRqOha3B3toDoJ/eVBouFcVAYU2xBiIt4hefeF/S6oLaUS0E4 jQejOHllPFjUiZTtH4beLUTH/lBbqAqN1EPrptBntjmv77LjRg/nIrw3xEVztkV4SHDx rJMg== X-Gm-Message-State: AOAM532PBck6tZ8HTHDJeHHdUqG2Jinw+6/1AmMweCgivOgWXlLgmBsn xAbdcQ9vTB5XRy+jNSyqYquvlN4uAJVHeZQ3rslWIw== X-Received: by 2002:a17:906:bcfc:: with SMTP id op28mr4137917ejb.237.1591375193798; Fri, 05 Jun 2020 09:39:53 -0700 (PDT) MIME-Version: 1.0 References: <158889473309.2292982.18007035454673387731.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Fri, 5 Jun 2020 09:39:42 -0700 Message-ID: Subject: Re: [PATCH v2] ACPI: Drop rcu usage for MMIO mappings To: "Rafael J. Wysocki" Cc: 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 9:22 AM Rafael J. Wysocki wrote: [..] > > 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). I don't think you can replace the RCU usage in ACPI OSL and still maintain NMI lookups in a dynamic list. However, there are 3 solutions I see: - Prevent acpi_os_map_cleanup() from triggering at high frequency by pre-mapping and never unmapping operation-regions resources (internal discussion in progress) - Prevent walks of the 'acpi_ioremaps' list (acpi_map_lookup_virt()) from NMI context by re-writing the physical addresses in the APEI tables with pre-mapped virtual address, i.e. remove rcu_read_lock() and list_for_each_entry_rcu() from NMI context. - Split operation-region resources into a separate mapping mechanism than APEI resources so that typical locking can be used for the sleepable resources and let the NMI accessible resources be managed separately. That last one is one we have not discussed internally, but it occurred to me when you mentioned replacing RCU.