| Message ID | 1441513421-8092-3-git-send-email-yangyingliang@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. Thanks! Gerry > > Cc: Jiang Liu <jiang.liu@linux.intel.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Marc Zyngier <marc.zyngier@arm.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Will Deacon <will.deacon@arm.com> > Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> > Cc: Hanjun Guo <hanjun.guo@linaro.org> > Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> > --- > drivers/irqchip/irq-gic-v3.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index e406bc5..9108387 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -688,6 +688,7 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, > irq_domain_set_info(d, irq, hw, &gic_chip, d->host_data, > handle_fasteoi_irq, NULL, NULL); > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > + irq_set_move_pcntxt(irq); > } > /* LPIs */ > if (hw >= 8192 && hw < GIC_ID_NR) { > @@ -696,6 +697,7 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, > irq_domain_set_info(d, irq, hw, &gic_chip, d->host_data, > handle_fasteoi_irq, NULL, NULL); > set_irq_flags(irq, IRQF_VALID); > + irq_set_move_pcntxt(irq); > } > > return 0; >
On 2015/9/6 13: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. > Thanks! > Gerry I am not certain sure if GICv3 supports it. But current code consider it as true default without CONFIG_GENERIC_PENDING_IRQ enable on arm. Does Marc have any opinion ? Thanks Yang > >> >> Cc: Jiang Liu <jiang.liu@linux.intel.com> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Marc Zyngier <marc.zyngier@arm.com> >> Cc: Mark Rutland <mark.rutland@arm.com> >> Cc: Will Deacon <will.deacon@arm.com> >> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> >> Cc: Hanjun Guo <hanjun.guo@linaro.org> >> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> >> --- >> drivers/irqchip/irq-gic-v3.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c >> index e406bc5..9108387 100644 >> --- a/drivers/irqchip/irq-gic-v3.c >> +++ b/drivers/irqchip/irq-gic-v3.c >> @@ -688,6 +688,7 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, >> irq_domain_set_info(d, irq, hw, &gic_chip, d->host_data, >> handle_fasteoi_irq, NULL, NULL); >> set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); >> + irq_set_move_pcntxt(irq); >> } >> /* LPIs */ >> if (hw >= 8192 && hw < GIC_ID_NR) { >> @@ -696,6 +697,7 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, >> irq_domain_set_info(d, irq, hw, &gic_chip, d->host_data, >> handle_fasteoi_irq, NULL, NULL); >> set_irq_flags(irq, IRQF_VALID); >> + irq_set_move_pcntxt(irq); >> } >> >> return 0; >> > > . >
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? Thanks, M.
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. 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. All architectures which do not select GENERIC_PENDING_IRQ are using the direct method. Thanks, tglx
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.
On Mon, 7 Sep 2015, Marc Zyngier wrote: > On 07/09/15 14:24, Thomas Gleixner wrote: > > 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... Go figure .... > 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? Looks like. We can distangle that, if this code needs to be reusable. Thanks, tglx
On 2015/9/7 22:56, Marc Zyngier wrote: > 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... X86 has special handling of this case when hot-removing a CPU. Basically, it does: 1) mask an irq 2) migrate irq to other cpus with set_affinity 3) redirect(retrigger) irq to other CPUs if it's pending on the CPU to be removed. Thanks! Gerry > >> 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. >
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index e406bc5..9108387 100644 --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -688,6 +688,7 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, irq_domain_set_info(d, irq, hw, &gic_chip, d->host_data, handle_fasteoi_irq, NULL, NULL); set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); + irq_set_move_pcntxt(irq); } /* LPIs */ if (hw >= 8192 && hw < GIC_ID_NR) { @@ -696,6 +697,7 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, irq_domain_set_info(d, irq, hw, &gic_chip, d->host_data, handle_fasteoi_irq, NULL, NULL); set_irq_flags(irq, IRQF_VALID); + irq_set_move_pcntxt(irq); } return 0;
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(). Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> --- drivers/irqchip/irq-gic-v3.c | 2 ++ 1 file changed, 2 insertions(+)