public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Chen Yu <yu.c.chen@intel.com>, Juergen Gross <jgross@suse.com>
Cc: Len Brown <len.brown@intel.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org, Chen Yu <yu.chen.surf@gmail.com>,
	Chen Yu <yu.c.chen@intel.com>, Wendy Wang <wendy.wang@intel.com>
Subject: Re: [RFC PATCH] genirq: Exclude managed irq during irq migration
Date: Wed, 25 Oct 2023 16:34:59 +0200	[thread overview]
Message-ID: <87v8au6a98.ffs@tglx> (raw)
In-Reply-To: <20231020072522.557846-1-yu.c.chen@intel.com>

Chen!

On Fri, Oct 20 2023 at 15:25, Chen Yu wrote:
> The managed IRQ will be shutdown and not be migrated to

Please write out interrupts in change logs, this is not twitter.

> other CPUs during CPU offline. Later when the CPU is online,
> the managed IRQ will be re-enabled on this CPU. The managed
> IRQ can be used to reduce the IRQ migration during CPU hotplug.
>
> Before putting the CPU offline, the number of the already allocated
> IRQs on this offlining CPU will be compared to the total number

The usage of IRQs and vectors is slightly confusing all over the
place.

> of available IRQ vectors on the remaining online CPUs. If there is
> not enough slot for these IRQs to be migrated to, the CPU offline
> will be terminated. However, currently the code treats the managed
> IRQ as migratable, which is not true, and brings false negative
> during CPU hotplug and hibernation stress test.

Your assumption that managed interrupts cannot be migrated is only
correct when the managed interrupts affinity mask has exactly one online
target CPU. Otherwise the interrupt is migrated to one of the other
online CPUs in the affinity mask.

Though that does not affect the migrateability calculation because in
case that a managed interrupt has an affinity mask with more than one
target CPU set, the vectors on the currently not targeted CPUs are
already reserved and accounted for in matrix->global_available. IOW,
migrateability for such managed interrupts is already guaranteed.

I'll amend the changelog to make this clear.

Thanks,

        tglx

  reply	other threads:[~2023-10-25 14:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20  7:25 [RFC PATCH] genirq: Exclude managed irq during irq migration Chen Yu
2023-10-25 14:34 ` Thomas Gleixner [this message]
2023-10-26  7:02   ` Chen Yu
2023-10-25 14:36 ` Thomas Gleixner
2023-10-25 15:31 ` [tip: irq/core] genirq/matrix: Exclude managed interrupts in irq_matrix_allocated() tip-bot2 for Chen Yu

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=87v8au6a98.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=dan.j.williams@intel.com \
    --cc=jgross@suse.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=wendy.wang@intel.com \
    --cc=yu.c.chen@intel.com \
    --cc=yu.chen.surf@gmail.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