RE: [Xen-devel] [PATCH] Reuse irq number for virq/ipi after vcpu unplug/plug

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

So, attached patch zeros irq stats at bind_evtchn_to_cpu, since
rate of change is the real concern. By this way, we don't need to
care whether stale stats are on multiple cpus at irq unbinding.

Thanks,
Kevin.
 
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: 2007年2月4日 22:39
>
>On 4/2/07 12:28, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> Another point I'm not for sure is the save/restore and migration.
>> From user perspective, he has no knowledge that cpu1...N are
>> unplugged and then plugged along the process. Thus will anyone
>> feel strange about the fact that all cpus except cpu0 gets their
>> per-vcpu interrupt stats empty after restored or migrated? This
>> seems not an explicit lifetime restart...
>
>...and the same is true for his network and block-device interrupts.
>Currently these may come back with different IRQs too, and 
>'fixing' this
>would be somewhat painful (e.g., it would probably need some evtchn
>interface changes). Why do you consider the VIRQs/IPIs so special?
>
>Your original point that having non-zero counts for CPU!=n for 
>an interrupt
>that is specific to CPU==n looks weird and may confuse people 
>is a fair one.
>Zeroing stats is a nice simple solution to that.
>
>As you say /proc/interrupts is used for IRQ load balancing, 
>where rate of
>change matters. I'm not aware of any other application uses of
>/proc/interrupts -- certainly none that are 'stateful' in 
>terms of requiring
>a given interrupt source to stick with its original IRQ, or 
>require accurate
>aggregate counts.
>
> -- Keir
>

Attachment: zero_irqstats_at_unbind.patch
Description: zero_irqstats_at_unbind.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel