public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yujie Liu <yujie.liu@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
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: Wed, 10 May 2023 15:24:45 +0800	[thread overview]
Message-ID: <ZFtGvfDFLyHeFVFH@yujie-X299> (raw)
In-Reply-To: <87mt2f2mhm.ffs@tglx>

[-- Attachment #1: Type: text/plain, Size: 4167 bytes --]

Hi Thomas,

On Mon, May 08, 2023 at 11:36:37AM +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?

Sorry, my previous info was incorrect.

The block/008 (do IO while hotplugging CPUs) failure also happens on a
64-bit kernel no matter having 'intremap=off' or not, and persists when
tested against v6.3, but the warning in default_send_IPI_mask_logical
function is not triggered on a 64-bit kernel. Not sure if that function
is 32-bit specific since it is set in arch/x86/kernel/apic/probe_32.c.

== x86_64 kernel ==

compiler/disk/kconfig/rootfs/tbox_group/test/testcase:
  gcc-11/1SSD/x86_64-rhel-8.3-func/debian-11.1-x86_64-20220510.cgz/lkp-skl-d06/block-group-00/blktests

commit:
  v6.3
  32c58fc685e5c ("genirq: Use the maple tree for IRQ descriptors management")

            v6.3 32c58fc685e5cd6b5947a5f8e9a
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
           :10          70%           7:7     blktests.block/008.fail
           :10          70%           7:7     blktests.block/012.fail

== i386 kernel ==

compiler/disk/kconfig/rootfs/tbox_group/test/testcase:
  gcc-11/1SSD/i386-debian-10.3-func/debian-11.1-i386-20220923.cgz/lkp-skl-d06/block-group-00/blktests

commit:
  v6.3
  32c58fc685e5c ("genirq: Use the maple tree for IRQ descriptors management")

            v6.3 32c58fc685e5cd6b5947a5f8e9a
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
           :20          90%          18:49    blktests.block/008.fail
           :20          90%          18:49    blktests.block/012.fail
           :20          80%          16:49    dmesg.EIP:default_send_IPI_mask_logical
           :20          80%          16:49    dmesg.WARNING:at_arch/x86/kernel/apic/ipi.c:#default_send_IPI_mask_logical

> >>   2) Can you enable the irq_vector:vector_*.* tracepoints and provide
> >>      the trace?
> >
> > Nothing was written to trace buffer, seems like no irq_vector events
> > were captured during this test.
> 
> Can you please apply the patch below? No need to enable the irq_vector
> events. It just dumps the information into dmesg.

The dmesgs of 64-bit and 32-bit kernels are attached.

--
Best Regards,
Yujie

> ---
> --- 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);
>  

[-- Attachment #2: dmesg_i386.xz --]
[-- Type: application/x-xz, Size: 42560 bytes --]

[-- Attachment #3: dmesg_x86_64.xz --]
[-- Type: application/x-xz, Size: 75076 bytes --]

  reply	other threads:[~2023-05-10  7:28 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
2023-05-10  7:24               ` Yujie Liu [this message]
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=ZFtGvfDFLyHeFVFH@yujie-X299 \
    --to=yujie.liu@intel.com \
    --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=tglx@linutronix.de \
    --cc=vsethi@nvidia.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