[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sun, 04 Feb 2007 14:39:22 +0000
  • Delivery-date: Sun, 04 Feb 2007 06:39:04 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdHTqIuaJIC5LiAQZGiyexI3PPLIQAyY637AA7yNvAABZImIQ==
  • Thread-topic: [Xen-devel] [PATCH] Reuse irq number for virq/ipi after vcpu unplug/plug

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.