|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] irqbalance?
At 18:13 17/07/2007, pak333@xxxxxxxxxxx wrote: resending as i did not receive a response. Anyone out there familiar with irq codethanks Prabha Hi All,If I turn off irqbalance xen/arch/x86/irq.c, does that actually stop XEN from balancing irqs across different physical cpus, or will that override the setting if there are too many interrupts and one of the cpus is overloaded. I don't know this, but it makes little sense to have a feature to turn something off if it's not actually turning it off. How would you like it if your lightswitches in the house decided to turn on the lights because it was too dark? Example: i have 4 cpus and i have configured irqbalance= off, so there is no irqbalancing done by xen. That is what I'd expect. Now if i have affintized all my physical interrupts to one cpu say cpu1 all the interrutps should be handled by the cpu1 and so should all the softirqs generated. Now what happens if one of the other cpus is lightly loaded, will some of the softirqs be queued against the other cpus or will cpu1 handle all interrupts and softirqs. I'd like to point out that (at least in my understanding) softirq's and "real" irq's aren't strictly related, so you could well have a SOFTIRQ as a result of a hard IRQ on a different CPU - that's again a "my understanding", rather than something I've read in the code, but I believe my understanding is correct. Also, to the best of my understanding, setting the IRQ affinity would essentially be the same as turning irq-balance off (for that interrupt). Looks to me like there are two levels of interrupt redirection, one done by the hardware where each physical device interrupt is assigned to a particual processor dynamically and then on top of that is the irqbalancing done by Xen itself. Is that true? and irqbalance=off only affects the latter and interrupt affinitzation is for the former? Affinity is a setting to restrict an interrupt (or other types of processing, e.g. threads, processes or VMs) to a certain processor - irq-balancing is "the opposite", e.g. that it attempts to move IRQ's around so that they are not all happening on a particular processor - this can be done in several different ways, either spreading one particular interrupt between the available processors, or by spreading several interrupts, so for example a Network interrupt happens always on one CPU, but another CPU takes disk interrupts, a third CPU takes all the timer interrupts, etc. There's no firm and fast rule of which is better (obviously, if interrupts happen VERY frequently, then the cache would work better if they are all on one CPU). Also, if you have a NUMA architecture where the time to "get to" a certain device is dependant on which physical CPU the code is running on, then it would be better for the IRQ to be on the CPU "nearest" to the device. All of these options have advantages and drawbacks.I guess this is still related to your scheduler questions previously, but I'm not certain I understand what you're actually trying to achieve: preventing interrupts from being processed may give you better performance for the CPU-bound tasks, but in general it's better for OVERALL performance of the system if the I/O performance is improved - as it generally has very small impact on the CPU intensive performance, but I/O performance can easily be very badly affected by delays (latency) added to the path of the IO-request. -- Mats _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |