用戶調度問題演算法

❶ 調度演算法有哪些

先來先服務(FCFS, First Come First Serve)
時間片輪轉法
多級反饋隊列演算法(Round Robin with Multiple Feedback)
最短進程優先
最短剩餘時間優先
最高響應比優先
常用的應該就這么幾種吧 具體實現演算法原理其實不是很難

❷ 哪些調度演算法需要不考慮用戶信道質量

無線資源管理主要包括切換控制、功率控制、接入控制、負荷控制以及分組調度等方面的內容。
無線資源管理是3G系統無線網路控制器（RNC）的重要組成部分，其主要作用是負責空中介面資源的分配和使用，確保用戶業務的服務質量、系統規劃的覆蓋區域以及提高系統容量。在3G的演進過程中，標准化組織3GPP和 3GPP2也在不斷完善和增強相關技術。對於分組調度演算法，一方面要考慮到演算法實現的復雜度，另一方面需要注意對系統性能指標的影響，如公平性、時延、業務的服務質量（QoS）等。目前採用比較多的調度演算法主要有輪循調度、最大載干比調度、比例公平調度三種類型。
在分組通信中，為了獲得統計復用增益，需要多個業務流共享帶寬。因此，當多個用戶爭用資源時，就需要有一種機制來確定服務次序，有效地分配無線資源，這就是分組調度。由於無線信道時變特性、帶寬資源有限和移動台功率受限等因素的影響，無線網路中的分組調度演算法有別於有線網路。
調度器首先根據信道狀態監視/預測模塊提供的信道信息和用戶的隊列狀態，依據一定的調度演算法，計算出每個用戶的優先順序，然後根據優先順序對用戶數據排隊，並分配無線資源，最後送到發射機。
1．Round Robin 輪叫調度（Round-Robin Scheling） 狹義解釋：
時間片輪轉演算法的基本思想是，系統將所有的就緒進程按先來先服務演算法的原則，排成一個隊列，每次調度時，系統把處理機分配給隊列首進程，並讓其執行一個時間片。當執行的時間片用完時，由一個計時器發出時鍾中斷請求，調度程序根據這個請求停止該進程的運行，將它送到就緒隊列的末尾，再把處理機分給就緒隊列中新的隊首進程，同時讓它也執行一個時間片。
廣義解釋：
時間片輪轉調度是一種最古老，最簡單，最公平且使用最廣的演算法是時間片調度。每個進程被分配一個時間段，稱作它的時間片，即該進程允許運行的時間。如果在時間片結束時進程還在運行，則CPU將被剝奪並分配給另一個進程。如果進程在時間片結束前阻塞或結束，則CPU當即進行切換。調度程序所要做的就是維護一張就緒進程列表，，當進程用完它的時間片後，它被移到隊列的末尾

❸ 調度演算法的調度演算法

在操作系統中調度是指一種資源分配，因而調度演算法是指：根據系統的資源分配策略所規定的資源分配演算法。對於不同的的系統和系統目標，通常採用不同的調度演算法，例如，在批處理系統中，為了照顧為數眾多的段作業，應採用短作業優先的調度演算法；又如在分時系統中，為了保證系統具有合理的響應時間，應當採用輪轉法進行調度。目前存在的多種調度演算法中，有的演算法適用於作業調度，有的演算法適用於進程調度；但也有些調度演算法既可以用於作業調度，也可以用於進程調度。
通常將作業或進程歸入各種就緒或阻塞隊列。
調度演算法要求：高資源利用率、高吞吐量、用戶滿意等原則。
進程調度所採用的演算法是與整個系統的設計目標相一致的：
1.批處理系統：增加系統吞吐量和提高系統資源的利用率;
2.分時系統：保證每個分時用戶能容忍的響應時間。
3.實時系統：保證對隨機發生的外部事件做出實時響應。

❹ 關於操作系統中調度演算法的問題

1. 這只是考題，而不是現實

2. 現實中可以通過多次運行一個程序的結果統計平均運行時間
   

❺ 什麼演算法能解決多對多調度問題

我們也糾結啊

❻ 為什麼說多級反饋隊列調度演算法能較好的滿足各方面用戶需要

多級反饋隊列調度演算法是一種性能較好的作業低級調度策略，能夠滿足各類用戶的需要。對於分時交互型短作業，系統通常可在第一隊列（高優先順序隊列）規定的時間片內讓其完成工作，使終端型用戶都感到滿意；對短的批處理作業，通常，只需在第一或第一、第二隊列（中優先順序隊列）中各執行一個時間片就能完成工作，周轉時間仍然很短；對長的批處理作業，它將依次在第一、第二、……，各個隊列中獲得時間片並運行，決不會出現得不到處理的情況。此系統模擬了多級反饋隊列調度演算法及其實現

❼ 貪心演算法多機調度問題偽代碼

void machineWork::Sort( int timeId[] )
{
for( int i = 0 ; i < works ; i++ )
timeId[i] = i;
for( i = 0 ; i < works - 1 ; i++ )
{
double min = timesUnsorted[ timeId[i] ];
int p = i;
for( int j = i + 1 ; j < works ; j++ )
{
if( this->timesUnsorted[ timeId[j] ] > min )
{
min = this->timesUnsorted[ timeId[j] ];
p = j;
}
}
int t = timeId[i];
timeId[i] = timeId[p];
timeId[p] = t;
}
}

❽ 作業的調度演算法有幾種各自的優缺點是什麼

先來先服務
時間片輪轉
最短作業優先
多級反饋隊列
優先順序
最高響應比

❾ 請教linux下用戶態進程調度問題

在進行Linux系統操作的時候，有時候會遇到一次用戶態進程死循環，即系統反應遲鈍、進程掛死等問題，那麼遇到這些問題又該如何解決呢？下面小編就給大家介紹下一次用戶態進程死循環的問題該如何處理。
Linux下如何處理一次用戶態進程死循環問題
1、問題現象
業務進程（用戶態多線程程序）掛死，操作系統反應遲鈍，系統日誌沒有任何異常。從進程的內核態堆棧看，看似所有線程都卡在了內核態的如下堆棧流程中：
［root@vmc116 ~］# cat /proc/27007/task/11825/stack
［《ffffffff8100baf6》］ retint_careful+0x14/0x32
［《ffffffffffffffff》］ 0xffffffffffffffff
2、問題分析
1）內核堆棧分析
從內核堆棧看，所有進程都阻塞在 retint_careful上，這個是中斷返回過程中的流程，代碼（匯編）如下：
entry_64.S
代碼如下：
ret_from_intr：
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
decl PER_CPU_VAR（irq_count）
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP（%rsi）， %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
。。。
retint_careful：
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED，%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS（CLBR_NONE）
pushq_cfi %rdi
SCHEDULE_USER
popq_cfi %rdi
GET_THREAD_INFO（%rcx）
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
jmp retint_check
這其實是用戶態進程在用戶態被中斷打斷後，從中斷返回的流程，結合retint_careful+0x14/0x32，進行反匯編，可以確認阻塞的點其實就在
SCHEDULE_USER
這其實就是調用schele（）進行調度，也就是說當進程走到中斷返回的流程中時，發現需要調度（設置了TIF_NEED_RESCHED），於是在這里發生了調度。
有一個疑問：為什麼在堆棧中看不到schele（）這一級的棧幀呢？
因為這里是匯編直接調用的，沒有進行相關棧幀壓棧和上下文保存操作。
2）進行狀態信息分析
從top命令結果看，相關線程實際一直處於R狀態，CPU幾乎完全耗盡，而且絕大部分都消耗在用戶態：
［root@vmc116 ~］# top
top - 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62
Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie
Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st
Mem： 32878852k total， 32315464k used， 563388k free， 374152k buffers
Swap： 35110904k total， 38644k used， 35072260k free， 28852536k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
。。。
3）進程調度信息
從相關線程的調度信息看：
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15681811525768 129628804592612 3557465
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682016493013 129630684625241 3557509
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682843570331 129638127548315 3557686
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683323640217 129642447477861 3557793
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683698477621 129645817640726 3557875
發現相關線程的調度統計一直在增加，說明相關線程一直是在被調度運行的，結合其狀態也一直是R，推測很可能在用戶態發生了死循環（或者非睡眠死鎖）。
這里又有問題：為什麼從top看每個線程的CPU佔用率只有10%左右，而不是通常看到的死循環進程導致的100%的佔用率？
因為線程數很多，而且優先順序都一樣，根據CFS調度演算法，會平均分配時間片，不會讓其中一個線程獨佔CPU。結果為多個線程間輪流調度，消耗掉了所有的cpu。。
另一個問題：為什麼這種情況下，內核沒有檢測到softlockup？
因為業務進程的優先順序不高，不會影響watchdog內核線程（最高優先順序的實時線程）的調度，所以不會產生softlockup的情況。
再一個問題：為什麼每次查看線程堆棧時，總是阻塞在retint_careful，而不是其它地方？
因為這里（中斷返回的時候）正是調度的時機點，在其它時間點不能發生調度（不考慮其它情況~），而我們查看線程堆棧的行為，也必須依賴於進程調度，所以我們每次查看堆棧時，正是查看堆棧的進程（cat命令）得到調度的時候，這時正是中斷返回的時候，所以正好看到的阻塞點為retint_careful。
4）用戶態分析
從上面的分析看，推測應該是用戶態發生了死鎖。
用戶態確認方法：
部署debug信息，然後gdb attach相關進程，確認堆棧，並結合代碼邏輯分析。
最終確認該問題確為用戶態進程中產生了死循環。