From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753911AbbJARJu (ORCPT ); Thu, 1 Oct 2015 13:09:50 -0400 Received: from mga01.intel.com ([192.55.52.88]:31312 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750844AbbJARJt (ORCPT ); Thu, 1 Oct 2015 13:09:49 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,618,1437462000"; d="scan'208";a="656007608" Subject: Re: CPU hotplug and chained interrupts on x86 To: Thomas Gleixner , Mika Westerberg References: <20151001142147.GO1551@lahna.fi.intel.com> Cc: linux-kernel@vger.kernel.org From: Jiang Liu Organization: Intel Message-ID: <560D6850.10504@linux.intel.com> Date: Fri, 2 Oct 2015 01:07:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/10/1 22:31, Thomas Gleixner wrote: > On Thu, 1 Oct 2015, Mika Westerberg wrote: >> Now if I plug/unplug the card I may get few interrupts to CPU0 but rest >> of the interrupts never happen. Probably because IO-APIC forwards them >> to the lowest priority CPU which is offline at this point. >> >> There is following check in fixup_irqs(): >> >> if (!irq_has_action(irq) || irqd_is_per_cpu(data) || >> cpumask_subset(affinity, cpu_online_mask)) { >> raw_spin_unlock(&desc->lock); >> continue; >> } >> >> If an interrupt is requested by a driver it will force new affinity and >> everything works fine. However if the interrupt is chained (it does not >> have ->action) this is skipped and the current affinity remains. >> >> We could detect here if the interrupt is chained but there seems to be >> no easy way to determine it currently so we would need to add a new flag >> to desc->status_use_accessors that gets set in __irq_do_set_handler() >> when is_chained is 1. > > Either there or in irq_data. Need to look at it in detail. Currently we have no flag for chained, I suggested to add one dedicated flag for it. > >> Alternative I could implement ->irq_set_affinity() in the GPIO driver in >> question [1] which always calls directly parent chip's ->irq_set_affinity() >> but I'm not sure if that is allowed. > > I rather prefer to avoid that. We should report chained state and parent irq, so user and irqbalance may make smarter decision based on those info. Thanks! Gerry > > Thanks, > > tglx >