From: Thomas Gleixner <tglx@linutronix.de>
To: "Costa Shulyupin" <costa.shul@redhat.com>,
longman@redhat.com, ming.lei@redhat.com, pauld@redhat.com,
juri.lelli@redhat.com, vschneid@redhat.com,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Naveen N Rao" <naveen@kernel.org>,
"Zefan Li" <lizefan.x@bytedance.com>, "Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Ingo Molnar" <mingo@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Dietmar Eggemann" <dietmar.eggemann@arm.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Ben Segall" <bsegall@google.com>, "Mel Gorman" <mgorman@suse.de>,
"Costa Shulyupin" <costa.shul@redhat.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: Re: [RFC PATCH v3 2/3] genirq/cpuhotplug: Adjust managed irqs according to change of housekeeping CPU
Date: Wed, 02 Oct 2024 12:09:38 +0200 [thread overview]
Message-ID: <87h69uyfx9.ffs@tglx> (raw)
In-Reply-To: <20240916122044.3056787-3-costa.shul@redhat.com>
On Mon, Sep 16 2024 at 15:20, Costa Shulyupin wrote:
> Interrupts disturb real-time tasks on affined cpus.
> To ensure CPU isolation for real-time tasks, interrupt handling must
> be adjusted accordingly.
> Non-managed interrupts can be configured from userspace,
> while managed interrupts require adjustments in kernelspace.
>
> Adjust status of managed interrupts according change
> of housekeeping CPUs to support dynamic CPU isolation.
What means 'adjust status' ?
> +
> +/*
> + * managed_irq_isolate() - Deactivate managed interrupts if necessary
> + */
> +// derived from migrate_one_irq, irq_needs_fixup, irq_fixup_move_pending
If at all then this needs to be integrated with migrate_one_irq()
> +static int managed_irq_isolate(struct irq_desc *desc)
> +{
> + struct irq_data *d = irq_desc_get_irq_data(desc);
> + struct irq_chip *chip = irq_data_get_irq_chip(d);
> + const struct cpumask *a;
> + bool maskchip;
> + int err;
> +
> + /*
> + * Deactivate if:
> + * - Interrupt is managed
> + * - Interrupt is not per cpu
> + * - Interrupt is started
> + * - Effective affinity mask includes isolated CPUs
> + */
> + if (!irqd_affinity_is_managed(d) || irqd_is_per_cpu(d) || !irqd_is_started(d)
> + || cpumask_subset(irq_data_get_effective_affinity_mask(d),
> + housekeeping_cpumask(HK_TYPE_MANAGED_IRQ)))
> + return 0;
> + // TBD: it is required?
> + /*
> + * Complete an eventually pending irq move cleanup. If this
> + * interrupt was moved in hard irq context, then the vectors need
> + * to be cleaned up. It can't wait until this interrupt actually
> + * happens and this CPU was involved.
> + */
> + irq_force_complete_move(desc);
> +
> + if (irqd_is_setaffinity_pending(d)) {
> + irqd_clr_move_pending(d);
> + if (cpumask_intersects(desc->pending_mask,
> + housekeeping_cpumask(HK_TYPE_MANAGED_IRQ)))
> + a = irq_desc_get_pending_mask(desc);
> + } else {
> + a = irq_data_get_affinity_mask(d);
> + }
> +
> + maskchip = chip->irq_mask && !irq_can_move_pcntxt(d) && !irqd_irq_masked(d);
> + if (maskchip)
> + chip->irq_mask(d);
> +
> + if (!cpumask_intersects(a, housekeeping_cpumask(HK_TYPE_MANAGED_IRQ))) {
> + /*
> + * Shut managed interrupt down and leave the affinity untouched.
> + * The effective affinity is reset to the first online CPU.
> + */
> + irqd_set_managed_shutdown(d);
> + irq_shutdown_and_deactivate(desc);
> + return 0;
Seriously? The interrupt is active and the queue might have outstanding
requests which will never complete because the interrupt is taken away.
On CPU hotplug the related subsystem has shut down the device queue and
drained all outstanding requests. But none of this happens here.
> + }
> +
> + /*
> + * Do not set the force argument of irq_do_set_affinity() as this
> + * disables the masking of offline CPUs from the supplied affinity
> + * mask and therefore might keep/reassign the irq to the outgoing
> + * CPU.
Which outgoing CPU?
> + */
> + err = irq_do_set_affinity(d, a, false);
> + if (err)
> + pr_warn_ratelimited("IRQ%u: set affinity failed(%d).\n",
> + d->irq, err);
> +
> + if (maskchip)
> + chip->irq_unmask(d);
> +
> + return err;
> +}
> +
> +/** managed_irq_affinity_adjust() - Deactivate of restore managed interrupts
> + * according to change of housekeeping cpumask.
> + *
> + * @enable_mask: CPUs for which interrupts should be restored
> + */
> +int managed_irq_affinity_adjust(struct cpumask *enable_mask)
> +{
> + unsigned int irq;
> +
> + for_each_active_irq(irq) {
What ensures that this iteration is safe?
> + struct irq_desc *desc = irq_to_desc(irq);
And that the descriptor is valid?
> + unsigned int cpu;
> +
> + for_each_cpu(cpu, enable_mask)
> + irq_restore_affinity_of_irq(desc, cpu);
And what protects irq_restore_affinity_of_irq() against other operations
on @desc?
> + raw_spin_lock(&desc->lock);
What disables interrupts here in the runtime case?
> + managed_irq_isolate(desc);
> + raw_spin_unlock(&desc->lock);
> + }
> +
> + return 0;
That return value has which purpose?
None of this can work at runtime.
Thanks,
tglx
next prev parent reply other threads:[~2024-10-02 10:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 12:20 [RFC PATCH v3 0/3] genirq/cpuhotplug: Adjust managed interrupts according to change of housekeeping cpumask Costa Shulyupin
2024-09-16 12:20 ` [RFC PATCH v3 1/3] sched/isolation: Add infrastructure for dynamic CPU isolation Costa Shulyupin
2024-10-02 9:44 ` Thomas Gleixner
2024-09-16 12:20 ` [RFC PATCH v3 2/3] genirq/cpuhotplug: Adjust managed irqs according to change of housekeeping CPU Costa Shulyupin
2024-10-02 10:09 ` Thomas Gleixner [this message]
2024-09-16 12:20 ` [RFC PATCH v3 3/3] DO NOT MERGE: test for managed irqs adjustment Costa Shulyupin
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=87h69uyfx9.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bhelgaas@google.com \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=costa.shul@redhat.com \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lizefan.x@bytedance.com \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=ming.lei@redhat.com \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=mpe@ellerman.id.au \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).