From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03EECC433E0 for ; Sat, 25 Jul 2020 12:10:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BCC9420674 for ; Sat, 25 Jul 2020 12:10:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VzIFdJdW"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="L/x8l1MZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCC9420674 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7oQsQzmLiR50VemClMdN12SWtUvswdVnqnYyQ6CPAG8=; b=VzIFdJdWqag5AudKTlOafAQmH wzdMDLJUbmT0riv4/Qjm8nxG9jad3oL/218RBTQs6oX4Has0MMIS15BVf9MjgsZqWzoArc1J77CVd P1cHPbOUd8H42xCJzi2vK14/tMM4tHMyIv34T+/EVEbKghqkeTjj4JZMnDRBVnWIRGUsWwvVc10if jkTDE61VvYhUkHqYLoShxc0Y+lwb+PcHCmE2TSK0fuNEmN6mXNxuGpluwv7oq2uUfh1yAQeckKC9F zMmn3UO4FrgKk4gDOH8dXsFNgkgrKDOvE+pcKYBsiQWaSuvBSufkTO1OPOIJBMPOJhe6aygLJqL2e ruyY8z3hg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jzIyk-0004ar-JB; Sat, 25 Jul 2020 12:08:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jzIyi-0004a3-3I for linux-arm-kernel@lists.infradead.org; Sat, 25 Jul 2020 12:08:37 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E179720674; Sat, 25 Jul 2020 12:08:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595678914; bh=P2fyKAWwICs4KEcQ2YA/VKfeCFmFjqOOBXeOxw6GlGk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=L/x8l1MZX478b7h9FDYbNhu7NRy1DqkzZgprkEm70nR6lQLWl8AiC5xbyue8hWeTI ws+ekbetSwqxDRzTc4o9eqmi2ljk0ZWqSWoI1QAmrREmQjdT1GT/ZNoIcZHAz6eYYJ VGub7fgLrn0IbSNQTOpUl5YeicOhSn9D1XDAO8J8= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jzIye-00Epz5-2N; Sat, 25 Jul 2020 13:08:32 +0100 Date: Sat, 25 Jul 2020 13:08:31 +0100 Message-ID: <875zabyeyo.wl-maz@kernel.org> From: Marc Zyngier To: Thomas Gleixner Subject: Re: [PATCH V2] genirq/affinity: Handle affinity setting on inactive interrupts correctly In-Reply-To: <87h7twu1cp.fsf@nanos.tec.linutronix.de> References: <87k0z2s2q3.fsf@nanos.tec.linutronix.de> <877dv2rv25.fsf@nanos.tec.linutronix.de> <20200724182422.27ddced6.john@metanate.com> <87h7twu1cp.fsf@nanos.tec.linutronix.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: tglx@linutronix.de, john@metanate.com, linux-kernel@vger.kernel.org, x86@kernel.org, benh@amazon.com, alisaidi@amazon.com, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200725_080836_364038_14D0CCB4 X-CRM114-Status: GOOD ( 23.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ben Herrenschmidt , x86@kernel.org, LKML , John Keeping , Ali Saidi , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi both, On Fri, 24 Jul 2020 21:03:50 +0100, Thomas Gleixner wrote: > > John, > > John Keeping writes: > > On Fri, 17 Jul 2020 18:00:02 +0200 > > Thomas Gleixner wrote: > > It seems that this patch breaks perf events on RK3288 because the PMU > > interrupts that should be per-cpu are now all on CPU0 so no events are > > collected from CPUs 1-3 and those interrupts are killed as spurious > > after a few seconds. SPI-backed PMUs. Urgh... > > > > I'm seeing this on 4.19.134 and 5.4.53 but as far as I can tell the > > relevant code hasn't changed through to next-20200723. Reverting the > > backport of this change fixes the problem. > > Bah. > > > It looks like what happens is that because the interrupts are not > > per-CPU in the hardware, armpmu_request_irq() calls irq_force_affinity() > > while the interrupt is deactivated and then request_irq() with > > IRQF_PERCPU | IRQF_NOBALANCING. > > > > Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls > > irq_setup_affinity() which returns early because IRQF_PERCPU and > > IRQF_NOBALANCING are set, leaving the interrupt on its original CPU. > > Right. My brain tricked me to believe that we made activation mandatory, > but that's not. > > I have some ideas for a trivial generic way to solve this without > undoing the commit in question and without going through all the irq > chip drivers. So far everything I came up with is butt ugly. Maybe Marc > has some brilliant idea. Not really. We have contradicting behaviours here, where some interrupts want to see the set_affinity early (the above case), and some cannot handle that (x86 vectors and the GICv3 ITS). We could key it on the presence of an activate callback, but it feels fragile. I'll follow up on your patch in the next email, which seems like a sensible approach. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel