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

[Jan Beulich <JBeulich@xxxxxxxx>]

On 03.07.2019 19:58, Andrew Cooper wrote:
> 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).

With SMT off (on Intel systems) I've certainly observed every other bit
being set, which is why I had specifically decided against %*pbl. Plus
using %*pbl would break the tabular formatting. The only middle ground
I could see (still having the undesirable latter effect) would be to
pick between both forms based on the ratio between set bits and total
number of them (and perhaps using %*pb as long as the total number of
them is below a certain threshold). Thoughts?

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