Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4010257imu; Mon, 14 Jan 2019 13:10:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN4AnGtUbnUftZ4Wz+rCxycHZCftFvRkPPvisz9m90lqwLCBrri/M2hXaAntHAOGmURSkq4u X-Received: by 2002:a63:dc54:: with SMTP id f20mr459066pgj.410.1547500223725; Mon, 14 Jan 2019 13:10:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547500223; cv=none; d=google.com; s=arc-20160816; b=HqnbA+7tSoKpbJ6qa5ViVid+w+0nj3JVey0mgkzNej6ZMGSzjdNV+jNcGA9r7DpqoM ANjuSg3DqSDx4YgRYOQrsQiy+upbsPGaend/Y3yDp5R0vFjRs0148TOAcOjGtMywvq6t 73OjOYr0RzQzUVHGD+pE8dTIgGIrt0fTphtDiEYvjUoFhRtbtRqv2dEfn8bbrFvMq57w xoqb2hpLExGs/InN3HojRKdF2rxjHgPD1K7WX+pbjhcO9hi1BkXmsTFEvLa/Zd946Kl5 iJWhzMUxaGIue0vpIUBpN3XrnGbarbnohRMa0L6Kb8Hw55loiLEdGUDXHeMCpbX7gDoT ADvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:autocrypt:openpgp:from:references:cc:to :subject; bh=K+t7kZs4ApIti02VIA19BQZH2ZRzDgCASd4V+dV20ug=; b=Mrdu4BE6i5GXRR22nCCadiUuRDhDVxc/0qSLqEMW0zZ2Y9eWUyIbZ/ZLlxLIuj7o57 TLlxH4wVQ/2w5VMxE4cAd8AX+7vj9BPkDVjFsNRxHDZFts2NyVPLmUWB6R0dyy5VxZOD 7bkxNOypM2dswQvfN31SzK77kj77CYS89sF0QyGL7DB9ZZNReE2B3C2rRdPQ18esT8P5 eq2zCeyZEes5c74PlOS6WRhSVj6CWqAfBXw2v/Zk0wHC1dovk4mgyifE3l2WnljQ/Dkp JVFnZUJSkAgRJRCUKuNRU4nnuDEGIZy/2mswszwKHmc3pQ8qdIGMvwxObYe7BmxWWuLt i6YA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1si1247456pld.79.2019.01.14.13.10.07; Mon, 14 Jan 2019 13:10:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbfANVHg convert rfc822-to-8bit (ORCPT + 99 others); Mon, 14 Jan 2019 16:07:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49292 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726777AbfANVHg (ORCPT ); Mon, 14 Jan 2019 16:07:36 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7FC6858E42; Mon, 14 Jan 2019 21:07:35 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-223.bos.redhat.com [10.18.17.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id A8C065C1B4; Mon, 14 Jan 2019 21:07:34 +0000 (UTC) Subject: Re: Question about qspinlock nest To: James Morse , Peter Zijlstra Cc: Zhenzhong Duan , LKML , SRINIVAS References: <910e9fb6-d0df-4711-fe2b-244b3c20eb82@redhat.com> <20190110201217.GH2861@worktop.programming.kicks-ass.net> <20190114131613.GB10486@hirez.programming.kicks-ass.net> <830db851-d5cb-4081-8d72-e3f3a0a282df@arm.com> From: Waiman Long Openpgp: preference=signencrypt Autocrypt: addr=longman@redhat.com; prefer-encrypt=mutual; keydata= xsFNBFgsZGsBEAC3l/RVYISY3M0SznCZOv8aWc/bsAgif1H8h0WPDrHnwt1jfFTB26EzhRea XQKAJiZbjnTotxXq1JVaWxJcNJL7crruYeFdv7WUJqJzFgHnNM/upZuGsDIJHyqBHWK5X9ZO jRyfqV/i3Ll7VIZobcRLbTfEJgyLTAHn2Ipcpt8mRg2cck2sC9+RMi45Epweu7pKjfrF8JUY r71uif2ThpN8vGpn+FKbERFt4hW2dV/3awVckxxHXNrQYIB3I/G6mUdEZ9yrVrAfLw5M3fVU CRnC6fbroC6/ztD40lyTQWbCqGERVEwHFYYoxrcGa8AzMXN9CN7bleHmKZrGxDFWbg4877zX 0YaLRypme4K0ULbnNVRQcSZ9UalTvAzjpyWnlnXCLnFjzhV7qsjozloLTkZjyHimSc3yllH7 VvP/lGHnqUk7xDymgRHNNn0wWPuOpR97J/r7V1mSMZlni/FVTQTRu87aQRYu3nKhcNJ47TGY evz/U0ltaZEU41t7WGBnC7RlxYtdXziEn5fC8b1JfqiP0OJVQfdIMVIbEw1turVouTovUA39 Qqa6Pd1oYTw+Bdm1tkx7di73qB3x4pJoC8ZRfEmPqSpmu42sijWSBUgYJwsziTW2SBi4hRjU h/Tm0NuU1/R1bgv/EzoXjgOM4ZlSu6Pv7ICpELdWSrvkXJIuIwARAQABzR9Mb25nbWFuIExv bmcgPGxsb25nQHJlZGhhdC5jb20+wsF/BBMBAgApBQJYLGRrAhsjBQkJZgGABwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQbjBXZE7vHeYwBA//ZYxi4I/4KVrqc6oodVfwPnOVxvyY oKZGPXZXAa3swtPGmRFc8kGyIMZpVTqGJYGD9ZDezxpWIkVQDnKM9zw/qGarUVKzElGHcuFN ddtwX64yxDhA+3Og8MTy8+8ZucM4oNsbM9Dx171bFnHjWSka8o6qhK5siBAf9WXcPNogUk4S fMNYKxexcUayv750GK5E8RouG0DrjtIMYVJwu+p3X1bRHHDoieVfE1i380YydPd7mXa7FrRl 7unTlrxUyJSiBc83HgKCdFC8+ggmRVisbs+1clMsK++ehz08dmGlbQD8Fv2VK5KR2+QXYLU0 rRQjXk/gJ8wcMasuUcywnj8dqqO3kIS1EfshrfR/xCNSREcv2fwHvfJjprpoE9tiL1qP7Jrq 4tUYazErOEQJcE8Qm3fioh40w8YrGGYEGNA4do/jaHXm1iB9rShXE2jnmy3ttdAh3M8W2OMK 4B/Rlr+Awr2NlVdvEF7iL70kO+aZeOu20Lq6mx4Kvq/WyjZg8g+vYGCExZ7sd8xpncBSl7b3 99AIyT55HaJjrs5F3Rl8dAklaDyzXviwcxs+gSYvRCr6AMzevmfWbAILN9i1ZkfbnqVdpaag QmWlmPuKzqKhJP+OMYSgYnpd/vu5FBbc+eXpuhydKqtUVOWjtp5hAERNnSpD87i1TilshFQm TFxHDzbOwU0EWCxkawEQALAcdzzKsZbcdSi1kgjfce9AMjyxkkZxcGc6Rhwvt78d66qIFK9D Y9wfcZBpuFY/AcKEqjTo4FZ5LCa7/dXNwOXOdB1Jfp54OFUqiYUJFymFKInHQYlmoES9EJEU yy+2ipzy5yGbLh3ZqAXyZCTmUKBU7oz/waN7ynEP0S0DqdWgJnpEiFjFN4/ovf9uveUnjzB6 lzd0BDckLU4dL7aqe2ROIHyG3zaBMuPo66pN3njEr7IcyAL6aK/IyRrwLXoxLMQW7YQmFPSw drATP3WO0x8UGaXlGMVcaeUBMJlqTyN4Swr2BbqBcEGAMPjFCm6MjAPv68h5hEoB9zvIg+fq M1/Gs4D8H8kUjOEOYtmVQ5RZQschPJle95BzNwE3Y48ZH5zewgU7ByVJKSgJ9HDhwX8Ryuia 79r86qZeFjXOUXZjjWdFDKl5vaiRbNWCpuSG1R1Tm8o/rd2NZ6l8LgcK9UcpWorrPknbE/pm MUeZ2d3ss5G5Vbb0bYVFRtYQiCCfHAQHO6uNtA9IztkuMpMRQDUiDoApHwYUY5Dqasu4ZDJk bZ8lC6qc2NXauOWMDw43z9He7k6LnYm/evcD+0+YebxNsorEiWDgIW8Q/E+h6RMS9kW3Rv1N qd2nFfiC8+p9I/KLcbV33tMhF1+dOgyiL4bcYeR351pnyXBPA66ldNWvABEBAAHCwWUEGAEC AA8FAlgsZGsCGwwFCQlmAYAACgkQbjBXZE7vHeYxSQ/+PnnPrOkKHDHQew8Pq9w2RAOO8gMg 9Ty4L54CsTf21Mqc6GXj6LN3WbQta7CVA0bKeq0+WnmsZ9jkTNh8lJp0/RnZkSUsDT9Tza9r GB0svZnBJMFJgSMfmwa3cBttCh+vqDV3ZIVSG54nPmGfUQMFPlDHccjWIvTvyY3a9SLeamaR jOGye8MQAlAD40fTWK2no6L1b8abGtziTkNh68zfu3wjQkXk4kA4zHroE61PpS3oMD4AyI9L 7A4Zv0Cvs2MhYQ4Qbbmafr+NOhzuunm5CoaRi+762+c508TqgRqH8W1htZCzab0pXHRfywtv 0P+BMT7vN2uMBdhr8c0b/hoGqBTenOmFt71tAyyGcPgI3f7DUxy+cv3GzenWjrvf3uFpxYx4 yFQkUcu06wa61nCdxXU/BWFItryAGGdh2fFXnIYP8NZfdA+zmpymJXDQeMsAEHS0BLTVQ3+M 7W5Ak8p9V+bFMtteBgoM23bskH6mgOAw6Cj/USW4cAJ8b++9zE0/4Bv4iaY5bcsL+h7TqQBH Lk1eByJeVooUa/mqa2UdVJalc8B9NrAnLiyRsg72Nurwzvknv7anSgIkL+doXDaG21DgCYTD wGA5uquIgb8p3/ENgYpDPrsZ72CxVC2NEJjJwwnRBStjJOGQX4lV1uhN1XsZjBbRHdKF2W9g weim8xU= Organization: Red Hat Message-ID: <7b7ee9e9-013e-e647-cab6-b2d161983112@redhat.com> Date: Mon, 14 Jan 2019 16:07:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <830db851-d5cb-4081-8d72-e3f3a0a282df@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 14 Jan 2019 21:07:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/14/2019 08:54 AM, James Morse wrote: > Hi Peter, > > On 14/01/2019 13:16, Peter Zijlstra wrote: >> On Fri, Jan 11, 2019 at 06:32:58PM +0000, James Morse wrote: >>> On 10/01/2019 20:12, Peter Zijlstra wrote: >>>> On Thu, Jan 10, 2019 at 06:25:57PM +0000, James Morse wrote: >>>> The thing is, everything non-maskable (NMI like) really should not be >>>> using spinlocks at all. >>>> >>>> I otherwise have no clue about wth APEI is, but it sounds like horrible >>>> crap ;-) >>> I think you've called it that before!: its that GHES thing in drivers/acpi/apei. >>> >>> What is the alternative? bit_spin_lock()? >>> These things can happen independently on multiple CPUs. On arm64 these NMIlike >>> things don't affect all CPUs like they seem to on x86. >> It has nothing to do with how many CPUs are affected. It has everything >> to do with not being maskable. > (sorry, I didn't include any of the context, let me back-up a bit here:) > >> What avoids the trivial self-recursion: >> >> spin_lock(&) >> >> spin_lock(&x) >> ... wait forever more ... >> >> spin_unlock(&x) >> >> ? > If its trying to take the same lock, I agree its deadlocked. > If the sequence above started with , I agree its deadlocked. > > APEI/GHES is doing neither of these things. It take a lock that is only ever > taken in_nmi(). nmi_enter()s BUG_ON(in_nmi()) means these never become re-entrant. > > What is the lock doing? Protecting the 'NMI' fixmap slot in the unlikely case > that two CPUs end up in here at the same time. > > (I though x86's NMI masked NMI until the next iret?) > > > This is murkier on arm64 as we have multiple things that behave like this, but > there is an order to them, and none of them can interrupt themselves. > e.g. We can't take an SError during the SError handler. > > But we can take this SError/NMI on another CPU while the first one is still > running the handler. > > These multiple NMIlike notifications mean having multiple locks/fixmap-slots, > one per notification. This is where the qspinlock node limit comes in, as we > could have more than 4 contexts. Still it will be extremely unlikely to have more than 4 nested spinlock acquisitions with contention. Do you think it will be helpful to make the MAX_NODES parameter configurable to either 4 or 8? For x86, I think we can live with 4. On arm64, we can opt for 8 if you think there is a decent chance that more than 4 could be needed under certain circumstances. This will, of course, reduce the max NR_CPUS by half. Cheers, Longman