Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1639959ybe; Tue, 3 Sep 2019 01:04:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqy2BdnO3TmWr9y2lmd4CsG6qwrw/ANxMyokLnlj8Zf7UH4lW0fO2GwXaEdqRct6Aul6Goo3 X-Received: by 2002:a63:e213:: with SMTP id q19mr28680471pgh.180.1567497894694; Tue, 03 Sep 2019 01:04:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567497894; cv=none; d=google.com; s=arc-20160816; b=tL79E8kI42iYopSoi602rCmYugPL9iugCKtKkRhZvvkmwcbLo9JJ+Xr3R2KjodB3ky cTEHGcoUL5ApjHcJTu8kglNDxQf3ct97hiKu+rc+zFLQjzGTSdBQwQIVx5IghutCvXPw jDjn8KV7z3tcA8lyQAgOW0ReaW+tDe4yxgb+1YYqtzyg0CZzaIw4Edc1/ChR2ihCiuLY xBMtvg5DHHCssAKPcr1UXkdJxMWMRkqBrl+ZgOICG2dWBDtYAUvGWaN8D5JG2mrdly9e 2za4eAhAaWxXKzIeXOd5ey5vLAl8KOSBDbeSSFtLCLcQQixiI53/FzEIdosnZaqpOXIE UycQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=pHE12DCNXNsYqn5LirriNuNij/YmRuyZO4SqAyQa+F0=; b=qyeLgQqO4+ujwpQVbRy2qIs9PQp3uAIBd6aAZkz6cskv8Jjk4k6qQlGanrCTDlO/0C mrEJfuF32Clr/lGS6S+l3MO4eHv4wk/ZHiA6d36Z9FtyGi99DCMsJN50Rz9CYZpffFTS jsLGAR5AU+5zZ6gHuZiz7AluwBQvgjZmJQEOD4/UwjIkt5s9DKAJuxBWNR9YkkEqGpDz WjulpUWT/oIhrXyPJ2QFqo/Um3khv0OTAoNjaDizZPU/bzWiQevasBh4edewWT0IXXu6 Tmcgnl+BY78FvFqxts7CE/tLVbUjVJAYvrnrvxeqDVKDM+jdYqcXIL6l5K9cj0Ml1S6A ZIRA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m184si17450166pfb.127.2019.09.03.01.04.38; Tue, 03 Sep 2019 01:04:54 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727700AbfICIDj convert rfc822-to-8bit (ORCPT + 99 others); Tue, 3 Sep 2019 04:03:39 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:59025 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726062AbfICIDi (ORCPT ); Tue, 3 Sep 2019 04:03:38 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1i53mp-0001mB-C0; Tue, 03 Sep 2019 10:03:35 +0200 Date: Tue, 3 Sep 2019 10:03:35 +0200 From: Sebastian Andrzej Siewior To: Clark Williams Cc: bigeasy@linutronix.com, tglx@linutronix.com, linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PREEMPT_RT PATCH 2/3] i915: convert all irq_locks spinlocks to raw spinlocks Message-ID: <20190903080335.pe45dmgmjvdvbyd4@linutronix.de> References: <20190820003319.24135-1-clark.williams@gmail.com> <20190820003319.24135-3-clark.williams@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20190820003319.24135-3-clark.williams@gmail.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-08-19 19:33:18 [-0500], Clark Williams wrote: > From: Clark Williams > > The following structures contain a member named 'irq_lock'. > These three locks are of type spinlock_t and are used in > multiple contexts including atomic: > > struct drm_i915_private > struct intel_breadcrumbs > strict intel_guc > > Convert them all to be raw_spinlock_t so that lockdep and the lock > debugging code will be happy. What is your motivation to make the lock raw? I did the following: void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine) { - local_irq_disable(); - intel_engine_breadcrumbs_irq(engine); - local_irq_enable(); + if (IS_ENABLED(CONFIG_PREEMPT_RT_FULL)) { + intel_engine_breadcrumbs_irq(engine); + } else { + local_irq_disable(); + intel_engine_breadcrumbs_irq(engine); + local_irq_enable(); + } } and lockdep was quiet (+ ignoring/patching the lockdep-irq-off-asserts). The local_irq_disable() is here (my interpretation of the situation) because that function is called from process context while the remaining callers invoke intel_engine_breadcrumbs_irq() from the interrupt handler and it acquires irq_lock via a plain spin_lock(). That local_irq_disable() would be required if everyone did a _irqsave(). I tried to check how much worse the latency gets here but I didn't see anything in a brief test. What I saw however is that switching to fullscreen while playing a video gives me ~0.5 to ~2ms latency. This is has nothing to do with this change, I have to dig deeper… It might be one of the preempt_disable() section I just noticed. I would prefer to keep the lock non-raw unless there is actual need for it. Sebastian