From: Thomas Gleixner <tglx@linutronix.de>
To: Yujie Liu <yujie.liu@intel.com>
Cc: Shanker Donthineni <sdonthineni@nvidia.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Michael Walle <michael@walle.cc>,
Vikram Sethi <vsethi@nvidia.com>
Subject: Re: [PATCH v3 3/3] genirq: Use the maple tree for IRQ descriptors management
Date: Mon, 08 May 2023 11:36:37 +0200 [thread overview]
Message-ID: <87mt2f2mhm.ffs@tglx> (raw)
In-Reply-To: <ZFdbtipfTsIF0u6z@yujie-X299>
Yujie!
On Sun, May 07 2023 at 16:05, Yujie Liu wrote:
> Sorry for late reply as we were on public holiday earlier this week.
Holidays are more important and the problems do not run away :)
> On Fri, Apr 28, 2023 at 12:31:14PM +0200, Thomas Gleixner wrote:
>> Under the assumption that the code is correct, then the effect of this
>> patch is that it changes the timing. Sigh.
>>
>> 1) Does this happen with a 64-bit kernel too?
>
> It doesn't happen on a 64-bit kernel:
Ok. So one difference might be that a 64 bit kernel enables interrupt
rempping. Can you add 'intremap=off' to the kernel command line please?
>> 2) Can you enable the irq_vector:vector_*.* tracepoints and provide
>> the trace?
>
> I'm a beginner of kernel and not sure if I'm doing this correctly. Here
> are my test steps:
They are perfectly fine.
> # check the trace
> # cat /sys/kernel/debug/tracing/trace
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 0/0 #P:4
> #
> # _-----=> irqs-off/BH-disabled
> # / _----=> need-resched
> # | / _---=> hardirq/softirq
> # || / _--=> preempt-depth
> # ||| / _-=> migrate-disable
> # |||| / delay
> # TASK-PID CPU# ||||| TIMESTAMP FUNCTION
> # | | | ||||| | |
>
> Nothing was written to trace buffer, seems like no irq_vector events
> were captured during this test.
Stupid me. I completely forgot that this happens on the outgoing CPU at
a point where the tracer for that CPU is already shut down.
Can you please apply the patch below? No need to enable the irq_vector
events. It just dumps the information into dmesg.
Thanks,
tglx
---
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -57,7 +57,8 @@ static bool migrate_one_irq(struct irq_d
bool maskchip = !irq_can_move_pcntxt(d) && !irqd_irq_masked(d);
const struct cpumask *affinity;
bool brokeaff = false;
- int err;
+ int err, irq = d->irq;
+ bool move_pending;
/*
* IRQ chip might be already torn down, but the irq descriptor is
@@ -101,10 +102,16 @@ static bool migrate_one_irq(struct irq_d
* there is no move pending or the pending mask does not contain
* any online CPU, use the current affinity mask.
*/
- if (irq_fixup_move_pending(desc, true))
+ move_pending = irqd_is_setaffinity_pending(d);
+ if (irq_fixup_move_pending(desc, true)) {
affinity = irq_desc_get_pending_mask(desc);
- else
+ pr_info("IRQ %3d: move_pending=%d pending mask: %*pbl\n",
+ irq, move_pending, cpumask_pr_args(affinity));
+ } else {
affinity = irq_data_get_affinity_mask(d);
+ pr_info("IRQ %3d: move_pending=%d affinity mask: %*pbl\n",
+ irq, move_pending, cpumask_pr_args(affinity));
+ }
/* Mask the chip for interrupts which cannot move in process context */
if (maskchip && chip->irq_mask)
@@ -136,6 +143,9 @@ static bool migrate_one_irq(struct irq_d
brokeaff = false;
}
+ affinity = irq_data_get_effective_affinity_mask(d);
+ pr_info("IRQ %3d: Done: %*pbl\n", irq, cpumask_pr_args(affinity));
+
if (maskchip && chip->irq_unmask)
chip->irq_unmask(d);
next prev parent reply other threads:[~2023-05-08 9:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 15:57 [PATCH v3 0/3] Increase the number of IRQ descriptors for SPARSEIRQ Shanker Donthineni
2023-04-10 15:57 ` [PATCH v3 1/3] genirq: Use hlist for managing resend handlers Shanker Donthineni
2023-04-10 15:57 ` [PATCH v3 2/3] genirq: Encapsulate sparse bitmap handling Shanker Donthineni
2023-04-10 15:57 ` [PATCH v3 3/3] genirq: Use the maple tree for IRQ descriptors management Shanker Donthineni
2023-04-25 3:16 ` kernel test robot
2023-04-26 12:08 ` Thomas Gleixner
2023-04-28 1:33 ` Yujie Liu
2023-04-28 10:31 ` Thomas Gleixner
2023-05-07 8:05 ` Yujie Liu
2023-05-08 9:36 ` Thomas Gleixner [this message]
2023-05-10 7:24 ` Yujie Liu
2023-05-10 14:41 ` Thomas Gleixner
2023-05-10 14:49 ` Thomas Gleixner
2023-05-10 15:19 ` Shanker Donthineni
2023-05-10 17:15 ` Shanker Donthineni
2023-05-10 19:12 ` Thomas Gleixner
2023-05-10 16:02 ` Shanker Donthineni
2023-04-15 15:49 ` [PATCH v3 0/3] Increase the number of IRQ descriptors for SPARSEIRQ Shanker Donthineni
2023-04-15 21:50 ` Thomas Gleixner
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=87mt2f2mhm.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=maz@kernel.org \
--cc=michael@walle.cc \
--cc=oe-lkp@lists.linux.dev \
--cc=sdonthineni@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=yujie.liu@intel.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 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.