Re: [Xen-devel] [PATCH v3 04/15] x86/IRQ: desc->affinity should strictly represent the requested value

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Wei Liu <wei.liu2@citrix.com>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 04/15] x86/IRQ: desc->affinity should strictly represent the requested value
Date: Wed, 3 Jul 2019 18:58:52 +0100	[thread overview]
Message-ID: <100bb162-6a69-f911-57bb-c709d3e0f98f@citrix.com> (raw)
In-Reply-To: <5CDE910E0200007800230072@prv1-mh.provo.novell.com>

[-- Attachment #1.1: Type: text/plain, Size: 2646 bytes --]

On 17/05/2019 11:46, Jan Beulich wrote:
> @@ -2334,9 +2339,10 @@ static void dump_irqs(unsigned char key)
>  
>          spin_lock_irqsave(&desc->lock, flags);
>  
> -        printk("   IRQ:%4d aff:%*pb vec:%02x %-15s status=%03x ",
> -               irq, nr_cpu_ids, cpumask_bits(desc->affinity), desc->arch.vector,
> -               desc->handler->typename, desc->status);
> +        printk("   IRQ:%4d aff:%*pb/%*pb vec:%02x %-15s status=%03x ",
> +               irq, nr_cpu_ids, cpumask_bits(desc->affinity),
> +               nr_cpu_ids, cpumask_bits(desc->arch.cpu_mask),
> +               desc->arch.vector, desc->handler->typename, desc->status);

Taking a sample large system (Rome, with your x2apic series to be
specific), which is only half as large as typical high-end Skylake systems.

(XEN) IRQ information:
(XEN)    IRQ:   0 affinity:00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 vec:f0 type=IO-APIC-edge    status=00000000 time.c#timer_interrupt()
(XEN)    IRQ:   1 affinity:00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 vec:68 type=IO-APIC-edge    status=00000002 mapped, unbound
(XEN)    IRQ:   3 affinity:ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff vec:70 type=IO-APIC-edge    status=00000002 mapped, unbound
(XEN)    IRQ:   4 affinity:ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff vec:f1 type=IO-APIC-edge    status=00000000 ns16550.c#ns16550_interrupt()
(XEN)    IRQ:   5 affinity:00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 vec:78 type=IO-APIC-edge    status=00000002 mapped, unbound
(XEN)    IRQ:   6 affinity:00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 vec:88 type=IO-APIC-edge    status=00000002 mapped, unbound
(XEN)    IRQ:   7 affinity:ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff vec:90 type=IO-APIC-level   status=00000002 mapped, unbound
(XEN)    IRQ:   8 affinity:00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 vec:98 type=IO-APIC-edge    status=00000030 in-flight=0 domain-list=0:  8(---),
(XEN)    IRQ:   9 affinity:00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 vec:a0 type=IO-APIC-level   status=00000030 in-flight=1 domain-list=0:  9(PMM),

This change is going to double up the affinity block, which will make
the lines even longer.

Given that all examples I've ever spotted are either a single bit, or a
fully set block, {%*pbl} will render in a much shorter, and keep the
line length reasonable.  (This in practice applies to the previous patch
as well).

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 3135 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel