From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT
Date: Mon, 07 Sep 2015 15:56:37 +0100 [thread overview]
Message-ID: <55EDA5A5.9070805@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1509071502080.15006@nanos>
Hi Thomas,
On 07/09/15 14:24, Thomas Gleixner wrote:
> On Mon, 7 Sep 2015, Marc Zyngier wrote:
>> On 06/09/15 06:56, Jiang Liu wrote:
>>> On 2015/9/6 12:23, Yang Yingliang wrote:
>>>> Use irq_settings_set_move_pcntxt() helper irqs status with
>>>> _IRQ_MOVE_PCNTXT. So that it can do set affinity when calling
>>>> irq_set_affinity_locked().
>>> Hi Yingliang,
>>> We could only set _IRQ_MOVE_PCNTCT flag to enable migrating
>>> IRQ in process context if your hardware platform supports atomically
>>> change IRQ configuration. Not sure whether that's true for GICv3.
>>> If GICv3 doesn't support atomically change irq configuration, this
>>> change may cause trouble.
>>
>> I think it boils down to what exactly "process context" means here. If
>> this means "we do not need to mask the interrupt" while moving it, then
>> it should be fine (the GIC architecture guarantees that a pending
>> interrupt will be migrated).
>>
>> Is there any other requirement for this flag?
>
> The history of this flag is as follows:
>
> On x86 interrupts can only be safely migrated while the interrupt is
> handled.
Woa! That's creative! :-) I suppose this doesn't work very well with CPU
hotplug though...
> With the introduction of IRQ remapping this requirement
> changed. Remapped interrupts can be migrated in any context.
>
> If you look at irq_set_affinity_locked()
>
> if (irq_can_move_pcntxt(data) {
> irq_do_set_affinity(data,...)
> chip->irq_set_affinity(data,...);
> } else {
> irqd_set_move_pending(data);
> }
>
> So if IRQ_MOVE_PCNTXT is not set, we handle the migration of the
> interrupt from next the interrupt. If it's set set_affinity() is
> called right away.
OK, that is now starting to make more sense.
> All architectures which do not select GENERIC_PENDING_IRQ are using
> the direct method.
Right. On ARM, only the direct method makes sense so far (we have no
constraint such as the one you describe above).
So I wonder why we bother introducing the IRQ_MOVE_PCNTXT flag on ARM at
all. Is that just because migration.c is only compiled when
GENERIC_PENDING_IRQ is set?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Yang Yingliang <yangyingliang@huawei.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Hanjun Guo <hanjun.guo@linaro.org>
Subject: Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT
Date: Mon, 07 Sep 2015 15:56:37 +0100 [thread overview]
Message-ID: <55EDA5A5.9070805@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1509071502080.15006@nanos>
Hi Thomas,
On 07/09/15 14:24, Thomas Gleixner wrote:
> On Mon, 7 Sep 2015, Marc Zyngier wrote:
>> On 06/09/15 06:56, Jiang Liu wrote:
>>> On 2015/9/6 12:23, Yang Yingliang wrote:
>>>> Use irq_settings_set_move_pcntxt() helper irqs status with
>>>> _IRQ_MOVE_PCNTXT. So that it can do set affinity when calling
>>>> irq_set_affinity_locked().
>>> Hi Yingliang,
>>> We could only set _IRQ_MOVE_PCNTCT flag to enable migrating
>>> IRQ in process context if your hardware platform supports atomically
>>> change IRQ configuration. Not sure whether that's true for GICv3.
>>> If GICv3 doesn't support atomically change irq configuration, this
>>> change may cause trouble.
>>
>> I think it boils down to what exactly "process context" means here. If
>> this means "we do not need to mask the interrupt" while moving it, then
>> it should be fine (the GIC architecture guarantees that a pending
>> interrupt will be migrated).
>>
>> Is there any other requirement for this flag?
>
> The history of this flag is as follows:
>
> On x86 interrupts can only be safely migrated while the interrupt is
> handled.
Woa! That's creative! :-) I suppose this doesn't work very well with CPU
hotplug though...
> With the introduction of IRQ remapping this requirement
> changed. Remapped interrupts can be migrated in any context.
>
> If you look at irq_set_affinity_locked()
>
> if (irq_can_move_pcntxt(data) {
> irq_do_set_affinity(data,...)
> chip->irq_set_affinity(data,...);
> } else {
> irqd_set_move_pending(data);
> }
>
> So if IRQ_MOVE_PCNTXT is not set, we handle the migration of the
> interrupt from next the interrupt. If it's set set_affinity() is
> called right away.
OK, that is now starting to make more sense.
> All architectures which do not select GENERIC_PENDING_IRQ are using
> the direct method.
Right. On ARM, only the direct method makes sense so far (we have no
constraint such as the one you describe above).
So I wonder why we bother introducing the IRQ_MOVE_PCNTXT flag on ARM at
all. Is that just because migration.c is only compiled when
GENERIC_PENDING_IRQ is set?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2015-09-07 14:56 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-06 4:23 [RFC PATCH v1 0/4] arm/arm64: fix a migrating irq bug when hotplug cpu Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 4:23 ` [RFC PATCH v1 1/4] genirq: Introduce irq_settings_set_move_pcntxt() helper Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 22:08 ` Thomas Gleixner
2015-09-06 22:08 ` Thomas Gleixner
2015-09-07 1:49 ` Yang Yingliang
2015-09-07 1:49 ` Yang Yingliang
2015-09-06 4:23 ` [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 5:56 ` Jiang Liu
2015-09-06 5:56 ` Jiang Liu
2015-09-07 2:03 ` Yang Yingliang
2015-09-07 2:03 ` Yang Yingliang
2015-09-07 12:32 ` Marc Zyngier
2015-09-07 12:32 ` Marc Zyngier
2015-09-07 13:24 ` Thomas Gleixner
2015-09-07 13:24 ` Thomas Gleixner
2015-09-07 14:56 ` Marc Zyngier [this message]
2015-09-07 14:56 ` Marc Zyngier
2015-09-07 14:58 ` Thomas Gleixner
2015-09-07 14:58 ` Thomas Gleixner
2015-09-07 16:33 ` Jiang Liu
2015-09-07 16:33 ` Jiang Liu
2015-09-06 4:23 ` [RFC PATCH v1 3/4] genirq: rename config GENERIC_PENDING_IRQ to GENERIC_IRQ_MIGRATION Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 4:23 ` [RFC PATCH v1 4/4] arm/arm64: fix a migrating irq bug when hotplug cpu Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 5:55 ` Jiang Liu
2015-09-06 5:55 ` Jiang Liu
2015-09-07 2:33 ` Yang Yingliang
2015-09-07 2:33 ` Yang Yingliang
2015-09-06 8:07 ` [RFC PATCH v1 0/4] " Jiang Liu
2015-09-06 8:07 ` Jiang Liu
2015-09-07 2:54 ` Yang Yingliang
2015-09-07 2:54 ` Yang Yingliang
2015-09-07 1:54 ` Jiang Liu
2015-09-07 1:54 ` Jiang Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55EDA5A5.9070805@arm.com \
--to=marc.zyngier@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.