精通polling參數(shù)調(diào)優(yōu)的進(jìn)來幫幫忙吧

xfsoul

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒經(jīng)過思考(請(qǐng)?jiān)�諒我這么說,他們也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx ...

實(shí)在暈倒，BSD內(nèi)核中也有這樣質(zhì)量的代碼？

caibird3rd

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒經(jīng)過思考(請(qǐng)?jiān)�諒我這么說,他們也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx ...

不曉得是不是跟linux的大內(nèi)核鎖一樣，可以重復(fù)進(jìn)入的？
ether_poll（）說不定在別的地方還有調(diào)用到，所以要加鎖
大內(nèi)核鎖在linux里已經(jīng)很少用到了�？磥韑inux更注重性能的說法有一定道理

另外，不曉得FB有沒有針對(duì)Opteron的優(yōu)化？樓主用的Opteron應(yīng)該很牛啦

[ 本帖最后由 caibird3rd 于 2006-5-25 19:08 編輯 ]

xfsoul

還有更牛的，雙路Opteron 270，就是四個(gè)2.0G的Opteron處理器。
另外還有雙路雙核XEON，每個(gè)CPU都支持HT。系統(tǒng)應(yīng)該會(huì)認(rèn)出八個(gè)CPU。
不過在雙路Opteron 250上也無法改善FreeBSD性能的話。
就只有用linux了。

mirnshi

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒經(jīng)過思考(請(qǐng)?jiān)�諒我這么說,他們也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx ...

6.x中的代碼，不同呀。主版本3、5都不是很好，命短。

1. 
   
2. /*
   
3. * ether_poll is called from the idle loop.
   
4. */
   
5. void
   
6. ether_poll(int count)
   
7. {
   
8.         int i;
   
9. 
   
10.         NET_LOCK_GIANT();
    
11.         mtx_lock(&poll_mtx);
    
12. 
    
13.         if (count > poll_each_burst)
    
14.                 count = poll_each_burst;
    
15. 
    
16.         for (i = 0 ; i < poll_handlers ; i++)
    
17.                 pr[i].handler(pr[i].ifp, POLL_ONLY, count);
    
18. 
    
19.         mtx_unlock(&poll_mtx);
    
20.         NET_UNLOCK_GIANT();
    
21. }
    
22. static void
    
23. poll_idle(void)
    
24. {
    
25.         struct thread *td = curthread;
    
26.         struct rtprio rtp;
    
27. 
    
28.         rtp.prio = RTP_PRIO_MAX;        /* lowest priority */
    
29.         rtp.type = RTP_PRIO_IDLE;
    
30.         mtx_lock_spin(&sched_lock);
    
31.         rtp_to_pri(&rtp, td->td_ksegrp);
    
32.         mtx_unlock_spin(&sched_lock);
    
33. 
    
34.         for (;;) {
    
35.                 if (poll_in_idle_loop && poll_handlers > 0) {
    
36.                         idlepoll_sleeping = 0;
    
37.                         ether_poll(poll_each_burst);
    
38.                         mtx_lock_spin(&sched_lock);
    
39.                         mi_switch(SW_VOL, NULL);
    
40.                         mtx_unlock_spin(&sched_lock);
    
41.                 } else {
    
42.                         idlepoll_sleeping = 1;
    
43.                         tsleep(&idlepoll_sleeping, 0, "pollid", hz * 3);
    
44.                 }
    
45.         }
    
46. }
    

復(fù)制代碼

個(gè)人感覺，還是扔掉5.x吧，因?yàn)楫?dāng)初粗粗看了5.x，就覺得是個(gè)試驗(yàn)品，就沒有仔細(xì)看，一直在4.x上做。6.1出來了，應(yīng)該算是穩(wěn)定住了

mirnshi

原帖由 xfsoul 于 2006-5-25 19:36 發(fā)表
還有更牛的，雙路Opteron 270，就是四個(gè)2.0G的Opteron處理器。
另外還有雙路雙核XEON，每個(gè)CPU都支持HT。系統(tǒng)應(yīng)該會(huì)認(rèn)出八個(gè)CPU。
不過在雙路Opteron 250上也無法改善FreeBSD性能的話。
就只有用linux了。

個(gè)人以為，雙核并不是完全意義上的“雙CPU”，在目前的這種IA架構(gòu)上，CPU多了，不見得是好事，這些CPU調(diào)度起來都是件麻煩事。
從我目前了解到的以及實(shí)驗(yàn)數(shù)據(jù)來說，cpu的處理速度足夠了應(yīng)付中低端(1G及1G以下)，只是總線有問題，所以網(wǎng)絡(luò)的速度跟不上。

雨絲風(fēng)片

原帖由 xie_minix 于 2006-5-25 18:11 發(fā)表
我猜想,開發(fā)POLLING的團(tuán)隊(duì)有問題.他們對(duì)MUTEX的了解不夠,最起碼在5.3版本時(shí).
這是最要命的事情.
其次,寫代碼時(shí)沒經(jīng)過思考(請(qǐng)?jiān)�諒我這么說,他們也不容易),比如你看:
...

原作者在此：


但從André Oppermann的一篇文章來看，6.0專門針對(duì)SMP的情況對(duì)polling進(jìn)行了修改：

Interface Polling

The network interface polling implementation has been re-implemented to work correctly in SMP environments. Polling is no longer a global configuration variable but enabled or disabled individually per interface if the driver supports it. Most commonly found network drivers support polling.

而且，從kern_poll.c文件的cvs記錄來看，對(duì)鎖的使用進(jìn)行優(yōu)化的工作也一直在進(jìn)行，比如：
http://lists.freebsd.org/piperma ... ptember/051848.html

雨絲風(fēng)片

原帖由 xfsoul 于 2006-5-25 18:23 發(fā)表

實(shí)在暈倒，BSD內(nèi)核中也有這樣質(zhì)量的代碼？

先污染，后治理。

[ 本帖最后由 雨絲風(fēng)片 于 2006-5-26 08:51 編輯 ]

雨絲風(fēng)片

原帖由 mirnshi 于 2006-5-25 15:00 發(fā)表
將mbuf的尺寸增大，并不會(huì)帶來特別顯著的提高，系統(tǒng)會(huì)根據(jù)包的大小，自動(dòng)分拆的，大家可以看看協(xié)議棧的實(shí)現(xiàn)。 ...

請(qǐng)教一下，這個(gè)分拆體現(xiàn)在哪兒？

擴(kuò)大mbuf尺寸，不考慮是否真能提高性能，至少可以盡量避免系統(tǒng)使用mbuf鏈或者cluster。另外，樓主兩個(gè)網(wǎng)卡mtu一致，而且是二層轉(zhuǎn)發(fā)，似乎也涉及不到ip fragmentation的問題。所以請(qǐng)教這個(gè)“自動(dòng)分拆”的含義？

colddawn

他的意思是指包在mbuf和cluster的分拆而不是包數(shù)據(jù)本身分拆，所以跟MTU無關(guān)了，使用cluster是有好處的，例如對(duì)于同一包的數(shù)據(jù)處理可以直接通過指向cluster指針，增加引用計(jì)數(shù)器，避免數(shù)據(jù)復(fù)制等。如果不使用cluster可以大幅度增加性能當(dāng)初設(shè)計(jì)就不會(huì)有cluster了。

雨絲風(fēng)片

原帖由 colddawn 于 2006-5-26 09:47 發(fā)表
他的意思是指包在mbuf和cluster的分拆而不是包數(shù)據(jù)本身分拆，所以跟MTU無關(guān)了，使用cluster是有好處的，例如對(duì)于同一包的數(shù)據(jù)處理可以直接通過指向cluster指針，增加引用計(jì)數(shù)器，避免數(shù)據(jù)復(fù)制等。如果不使用clust ...

不是討論是否需要使用、當(dāng)時(shí)是否有必要設(shè)計(jì)cluster。我的意思很簡(jiǎn)單，系統(tǒng)是否使用mbuf鏈或者mcluster來存儲(chǔ)網(wǎng)絡(luò)數(shù)據(jù)都取決于mbuf的尺寸，既然把mbuf尺寸調(diào)整到足以存放樓主測(cè)試的全部數(shù)據(jù)，又何來“包在mbuf和cluster的分拆”呢？