关于中断负载分担的一点疑惑(ioapic)

124 views
Skip to first unread message

keven

unread,
Jun 29, 2010, 5:46:57 AM6/29/10
to Linux-...@zh-kernel.org
各位好:
我现在有一个4核的至强CPU,一张网卡。网卡中断只能有一个核来处理,因为我的业务是无状态的报文,所以想自己做一个HASH算法,在4个核之间平均分配中断。
看了一些资料和Intel的开发手册后,发现TPR可能是满足需求的入手点。但是在Intel的开发手册里面又有如下的一段话,我就不是很确信了。这段话的意思是对于至强CPU,他的中断不是由LAPIC来决定的,而是chipset
bus controller 来决定的,那么我的问题是
1.chipset bus controller 是什么东东,系统总线控制器?
2.chipset bus controller 选择的依据是什么,也是根据TPR还是其他算法
3.是不是这就意味着对于至强我修改TPR是没有意义的?
3.对于我上面的这个场景,各个有没有好的办法推荐的,irqbalance就算了。

如果我的理解有误,请帮忙指正。
section 10.6.2.4 Lowest Priority Delivery Mode
For systems based on the Intel Xeon processor, the chipset bus controller
accepts
messages from the I/O APIC agents in the system and directs interrupts to
the
processors on the system bus. When using the lowest priority delivery mode,
the
chipset chooses a target processor to receive the interrupt out of the set
of possible
targets.
_______________________________________________
Linux 内核开发中文邮件列表
Linux-...@zh-kernel.org
http://zh-kernel.org/mailman/listinfo/linux-kernel
Linux 内核开发中文社区: http://zh-kernel.org

Liu Hui

unread,
Jun 29, 2010, 11:04:06 PM6/29/10
to cheng...@gmail.com, Linux-...@zh-kernel.org
我感觉这个bus controller跟你说的东西没有关系。另外,中断往哪里转发本来就不是LAPIC决定的,而是由IOAPIC决定的。
根据字面意思,这个bus controller就是总线控制器,负责在总线上进行数据传输的,在这种情景下应该传递是中断消息,好像跟中断仲裁没有关系。


--
Thanks & Best Regards
Liu Hui
--

Jike Song

unread,
Jun 29, 2010, 11:15:29 PM6/29/10
to cheng...@gmail.com, Linux-...@zh-kernel.org
2010/6/29 keven <cheng...@gmail.com>:

> 各位好:
> 我现在有一个4核的至强CPU,一张网卡。网卡中断只能有一个核来处理,因为我的业务是无状态的报文,所以想自己做一个HASH算法,在4个核之间平均分配中断。
> 看了一些资料和Intel的开发手册后,发现TPR可能是满足需求的入手点。但是在Intel的开发手册里面又有如下的一段话,我就不是很确信了。这段话的意思是对于至强CPU,他的中断不是由LAPIC来决定的,而是chipset
> bus controller 来决定的,那么我的问题是
> 1.chipset bus controller 是什么东东,系统总线控制器?

以前很古老的时代,也就是P6的时代, LAPIC是通过专门的3-线 APIC Bus来连接的、中断消息也是走这个专门的APIC Bus。
从NetBurst开始, APIC Bus就消失了, 大家都用FSB,也就是"system bus"。

> 2.chipset bus controller 选择的依据是什么,也是根据TPR还是其他算法
> 3.是不是这就意味着对于至强我修改TPR是没有意义的?
> 3.对于我上面的这个场景,各个有没有好的办法推荐的,irqbalance就算了。
>

好像/sys还是/proc下每个irq都有一个bitmap,表示允许哪个(些)CPU(s)来处理。 不过对balance不一定有用。
几年前看的时候,Linux是PPR、TPR什么的一概不用,没法balance,不知道现在怎么样了。


> section 10.6.2.4 Lowest Priority Delivery Mode
> For systems based on the Intel Xeon processor, the chipset bus controller
> accepts
> messages from the I/O APIC agents in the system and directs interrupts to
> the
> processors on the system bus. When using the lowest priority delivery mode,
> the
> chipset chooses a target processor to receive the interrupt out of the set
> of possible
> targets.

Intel CPU越出越多,手册为了保持可读性, 管新一点的CPU都用“Xeon”来称呼了~

--
Thanks,
Jike

keven

unread,
Jun 30, 2010, 1:38:53 AM6/30/10
to oliver yang, linux-...@zh-kernel.org
谢谢大家的回复,我现在已经禁用了网卡的MSI模式 :)

1.我没有仔细研读过PCI规范,请问MSI/MSIX和IOAPIC是什么关系? MSI/MSIX也通过IOAPIC产生中断么?

2:Lowest Priority Delivery Mode应该不会被OS采用??
Q:请问这个是什么意思啊?现在的Linux 中断方法默认就是采用这种配置的啊,难道我又是outman了。。。

3:我感觉这个bus controller跟你说的东西没有关系。另外,
中断往哪里转发本来就不是LAPIC决定的,而是由 IOAPIC决定的。
Q:对,中断往哪儿是IOAPIC决定的,但是现在的情形是发给所有的CPU(默认),然后总线仲裁,选择其中一个作为胜利者。但是请看Intel开发手册里面的一句话(针对最低优先级)
“the


chipset chooses a target processor to receive the interrupt out of the set
of possible

targets”
这个chipset就是主板上的芯片组? 另外他选择CPU的算法是什么? 我是否能够通过编程来修改?

望Intel的大牛或者主板厂商的兄弟以及各位朋友帮忙解答一下。

在 2010年6月29日 下午9:51,oliver yang <yango...@gmail.com>写道:

> IOAPIC只对INTX有意义,MSI/MSIX绑定CPU要看PCI 配置空间的capability结构定义。
> Lowest Priority Delivery Mode应该不会被OS采用。


>
> 在 2010年6月29日 下午5:46,keven <cheng...@gmail.com> 写道:

> --
> Cheers,
>
> Oliver Yang
>
> Twitter: http://twitter.com/yangoliver
> Blog: http://blog.csdn.net/yayong
> --------------------------------------------------------------------
> An OpenSolaris Developer

Jike Song

unread,
Jun 30, 2010, 1:46:13 AM6/30/10
to cheng...@gmail.com, linux-...@zh-kernel.org
2010/6/30 keven <cheng...@gmail.com>:

> 谢谢大家的回复,我现在已经禁用了网卡的MSI模式  :)
>
> 1.我没有仔细研读过PCI规范,请问MSI/MSIX和IOAPIC是什么关系? MSI/MSIX也通过IOAPIC产生中断么?

启用MSI/MSI-X之后, IOAPIC就被bypass了: MSI/MSI-X中断消息直接写到系统总线上,各个LAPIC都会监听到的,
之后丢弃、转发、或者处理。

IOAPIC是有硬件连线的, 它传的还是电平信号; MSI/MSIX完全没有线、电平了。

[中断投递和优先级那块,不是很了解(太TMD复杂了),不说了]

Reply all
Reply to author
Forward
0 new messages