[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 04/15] x86/IRQ: desc->affinity should strictly represent the requested value
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |