IO機制vs下半部機制vs并發(fā)控制機制

IO機制vs下半部機制vs并發(fā)控制機制Jet.chenJet.chen.g@目錄預備知識三種機制的比較下半部機制并發(fā)控制機制匯總驅(qū)動IO機制匯總FAQ預備知識1.三種線程:內(nèi)核線程、輕量級進程、用戶線程內(nèi)核線程：kthread_create()輕量級進程：clone()用戶線程：Pthread_create()2.一種進程:用戶進程linux普通應用：API：fork/vfork/clone/Linux中，每個XX都有一個task_struct，所以線程和進程可以使用同一調(diào)度器調(diào)度。因為Linux中進程的概念已經(jīng)被抽象成了計算狀態(tài)加資源的集合，這些資源在進程間可以共享。

為何要區(qū)分？使用資源和同步效率，調(diào)度開銷等都不一樣。知識預備-進程上下文和中斷上下文概念描述什么時候發(fā)生進程上下文主要是異常處理程序和內(nèi)核線程。內(nèi)核之所以進入進程上下文是因為進程自身的一些工作需要在內(nèi)核中做。例如，系統(tǒng)調(diào)用是為當前進程服務的，異常通常是處理進程導致的錯誤狀態(tài)等。所以在進程上下文中引用current是有意義的。進程調(diào)度；系統(tǒng)調(diào)用；中斷上下文是因為中斷信號而導致的中斷處理或軟中斷。而中斷信號的發(fā)生是隨機的，中斷處理程序及軟中斷并不能事先預測發(fā)生中斷時當前運行的是哪個進程，所以在中斷上下文中引用current是可以的，但沒有意義。事實上，對于A進程希望等待的中斷信號，可能在B進程執(zhí)行期間發(fā)生。例如，A進程啟動寫磁盤操作，A進程睡眠后現(xiàn)在時B進程在運行，當磁盤寫完后磁盤中斷信號打斷的是B進程，在中斷處理時會喚醒A進程。

發(fā)生中斷；

為什么在中斷上下文中不能休眠?原因在于中斷上下文不是一個進程上下文，其沒有一個專門用來描述CPU寄存器等信息的數(shù)據(jù)結構，所以無法被調(diào)度器調(diào)度。如果將中斷上下文也設計成進程上下文，那么調(diào)度器就可以對其進行調(diào)度，如果在開中斷的情況下，其自然就可以睡眠了。但是，如果這樣設計，那么中斷處理的效率將會降低。中斷（硬中斷、軟中斷）處理都是些耗時不是很長，對實時性要求很高，執(zhí)行頻度較高的應用，所以，如果采用一個專門的后臺daemon對其處理，顯然并不合適。三種機制的比較機制描述種類實現(xiàn)下半部機制

由下到上的

通知機制；軟中斷，工作隊列，tasklet，內(nèi)核定時器等；同步/異步IO機制

是由上到下（或者驅(qū)動程序自發(fā)）的

IO通信機制。分為阻塞IO(異步)與非阻塞IO(同步)

等待隊列，poll，epoll，Completions機制等并發(fā)控制機制提供并發(fā)控制機制，對共享資源進行保護。spinlock，mutex,信號量，中斷屏蔽、順序鎖(seqlock)、RCU(Read-Copy-Update)等在編程中

往往三者互相使用：

比如

hwm_sensor的驅(qū)動：用到（內(nèi)核定時器+工作隊列+mutex取決于

項目設計的需要。）Mtklogdump：就用到poll+等待隊列下半部機制機制是否在進程上下文是否在中斷上下文可否睡眠是否需要內(nèi)核線程性能CPU的支持特性是否需要調(diào)度應用場合軟中斷

yesYesNo可有可無，取決于調(diào)用時機高1）一個類型的軟中斷可以執(zhí)行在多個CPU；2）并發(fā)運行在多個CPU上（即使同一類型的也可以）。所以軟中斷必須設計為可重入的函數(shù)（允許多個CPU同時操作），因此也需要使用自旋鎖來保護其數(shù)據(jù)結構。YES考慮因素：多CPU;不可睡眠，不可阻塞；軟中斷是在編譯期間靜態(tài)分配；系統(tǒng)開銷相對小；設計難度高；適合執(zhí)行頻率高和連續(xù)性執(zhí)行要求高的情況，性能較高；應用：目前只有兩個子系直接使用軟中斷：網(wǎng)絡和SCSI。

例如在網(wǎng)絡子系統(tǒng)中，注冊了如下兩個softirq及其處理函數(shù)：open_softirq(NET_TX_SOFTIRQ,net_tx_action);--注冊softirqopen_softirq(NET_RX_SOFTIRQ,net_rx_action);--觸發(fā)softirq

taskletyesYESNO可有可無，取決于調(diào)用時機中1）一個類型的tasklet只能執(zhí)行在單個CPU；不能并行，只能串行執(zhí)行。

2）多個不同類型的tasklet可以并行在多個CPU上。

YES考慮因素：單CPU；不可睡眠，不可阻塞;動態(tài)分配；系統(tǒng)開銷相對??；設計難度?。贿m合執(zhí)行頻率低，連續(xù)性要求低的情況下；性能中；應用：TP,鍵盤，鼠標。大部分設備驅(qū)動都使用它。下半部機制工作隊列YESNOYESYES低1）每個工作隊列(僅限于MT)都會在每一個cpu上創(chuàng)建一個內(nèi)核線程。2）一個工作隊列可以在不同CPU上同時運行。YES考慮因素：多CPU;可睡眠，可阻塞；動態(tài)創(chuàng)建；系統(tǒng)開銷大；設計難度?。贿m合執(zhí)行頻率低，連續(xù)性要求低的情況下；需要考慮使用進程上下文的情況（信號，消息，內(nèi)存申請等）；性能低；應用：LED燈光控制；

內(nèi)核定時器noyesNOno較低同

軟中斷,實際上是一個軟中斷種類:TIMER_SOFTIRQ

yes考慮因素：需要在某段時間內(nèi)執(zhí)行的情況下使用；只執(zhí)行一次；應用：軟件定時器在設備驅(qū)動程序中被大量應用以檢測設備的狀態(tài)。

觸屏中斷檢測防抖動功能；init_timer（）Add_timer();Mod_timer();….

并發(fā)控制機制匯總From網(wǎng)絡并發(fā)控制機制匯總補充：1.順序鎖（seqlock）,RCU,也稱為

多核情況下，linux的無鎖編程算法）2.各種鎖，互斥量的實現(xiàn)基礎都是依靠原子操作完成。

semaphore又是在spinlock基礎上實現(xiàn)。3.Mutex比較semaphoreLinux驅(qū)動IO機制匯總序列概念描述通知方式"實現(xiàn)方式應用層次應用實例1阻塞：是指進程在執(zhí)行設備操作時，若不能獲得資源，則掛起進程直到滿足可操作的條件后再進行操作。注意：被掛起的進程會進入休眠狀態(tài)，它將被從調(diào)度器的運行隊列移走?？梢杂善渌绦騺韱拘驯蛔枞年犃?。Wait_event(&waiter)等待隊列內(nèi)核充電線程內(nèi);lcd刷屏；…..2異步通知：由設備通知進程可以訪問，實現(xiàn)異步的IO。有點類似阻塞IO。適當?shù)臅r候驅(qū)動程序調(diào)用kill_fasync()函數(shù)，使用信號SIGIO通知應用程序，設備準備就緒，可以執(zhí)行IO操作了。file_operations結構體中實現(xiàn):Fasync_struct結構體內(nèi)核+應用配合ccci；Audiodriver;3非阻塞IO:當進程在不能進行設備操作時，并不掛起，它或者放棄，或者不停的查詢，直到可以進行操作為止。應用自己決定什么時候放棄；POLL，Epoll，select，內(nèi)核+應用層；應用層;Mtklog;Logdump應用;4異步IO(AIO):也叫做異步I/O(AIO)，用戶程序可以通過向內(nèi)核發(fā)出I/O請求命令，不用等帶I/O事件真正發(fā)生，可以繼續(xù)做另外的事情，等I/O操作完成，通知方式：內(nèi)核會通過函數(shù)回調(diào)或者信號機制通知用戶進程。這樣很大程度提高了系統(tǒng)吞吐量。

1）Vs非阻塞IO：非阻塞IO中，如果設備資源不可用，則驅(qū)動程序返回EAGAIN，應用程序需要在適當?shù)臅r候進行重試，直到資源可用，IO請求成功執(zhí)行。而使用異步IO時，如果設備資源不可用，IO請求會排隊等待處理，驅(qū)動程序返回EIOCBQUEUED，應用程序不需要進行重試。

2）VS異步通知共同點：這兩種機制都有這樣一共通點：都可以在驅(qū)動層使用信號來通知應用層的程序做相應的I/O操作。在AIO中，可以使用信號和回調(diào)函數(shù)是實現(xiàn)內(nèi)核空間對用戶空間應用程序通知的兩種機制。

差異點：與異步通知相比較，異步通知強調(diào)的是設備就緒后，驅(qū)動程序主動通知應用程序。強調(diào)的是應用程序處于被動的一面。AIO強調(diào)的多次操作后查詢結果。概念本身有交疊的地方?？梢允褂眯盘柡突卣{(diào)函數(shù)是實現(xiàn)內(nèi)核空間對用戶空間應用程序通知file_operations結構體中實現(xiàn):

aio_read（）aio_write()等等

加上GNUC庫支持內(nèi)核+應用配合mtk的xlogFAQ1。linux內(nèi)核打印"BUG:schedulingwhileatomic"和"bad:schedulingfromtheidlethread"錯誤的時候，通常是在中斷處理函數(shù)中調(diào)用了可以休眠的函數(shù)，如semaphore,mutex,sleep之類的可休眠的函數(shù)，而linux內(nèi)核要求在中斷處理的時候，不允許系統(tǒng)高度，不允許搶占，要等到中斷處理完成才能做其他事情。因此，要充分考慮中斷處理的時間，一定不能太久Internalerror:Oops-BUG:0[#1]PREEMPTSMPARM原因就是mutextlock時間太長，導致的。例如：[154.941700]-([154.942751]-(0)[43:kworker/u:1][<c03c8e5c>](aee_wdt_irq_info+0x0/0x154)from[<c03c9070>](aee_wdt_fiq_info+0xc0/0xd0)[154.944090]-(0)[43:kworker/u:1]r9:c08f5fc0r8:00000096r7:00000000r6:00000000r4:00000000[154.945139]-(0)[43:kworker/u:1][<c0653688>](mutex_lock_nested+0x0/0x568)from[<c044d940>](synaptics_rmi4_i2c_read+0x60/0x290)[154.946582]-(0)[43:kworker/u:1][<c044e5bc>](synaptics_rmi4_sensor_wake+0x0/0x98)from[<c044e890>](synaptics_rmi4_resume+0x30/0xe0)[154.949603]-(0)[43:kworker/u:1]r6:00000000r5:c080365cr4:c092af20[154.950390]-(0)[43:kworker/u:1][<c044e860>](synaptics_rmi4_resume+0x0/0xe0)from[<c00b76d8>](late_resume+0x184/0x1b8)[154.951740]-(0)[43:kworker/u:1]r7:0000000br6:c0982198r5:c09ddec0r4:c092af20/u:1][<c00b7554>](late_resume+0x0/0x1b8)from[<c006af38>](process_one_work+0x1bc/0x58c)[154.953969]-(0)[43:kworker/u:1][<c006ad7c>](process_one_work+0x0/0x58c)from[<c006b494>](worker_thread+0x18c/0x3d8)[跟蹤到這里：mutex_lock(&(rmi4_data->rmi4_io_ctrl_mutex));觸發(fā)內(nèi)核異常//oldsize=4096nowchangeto2048

gprDMABuf_va=(u8*)dma_alloc_coherent(NULL,4096,&gprDMABuf_pa,GFP_KERNEL);

if(!gprDMABuf_va){printk("[Error]AllocateDMAI2CBufferfailed!\n");

}發(fā)現(xiàn)這個rmi4_io_ctrl_mutex的數(shù)值

前后不一致，說明或者傳入有問題，或者取數(shù)據(jù)時候有問題。首先私有數(shù)據(jù)rmi4_data與dev的綁定：FAQstaticintsynaptics_rmi4_set_input_dev(structsynaptics_rmi4_data*rmi4_data){intretval;inttemp;rmi4_data->input_dev=input_allocate_device();……………..input_set_drvdata(rmi4_data->input_dev,rmi4_data);是一個input設備類型}

staticintsynaptics_rmi4_resume(structdevice*dev){intretval;structsynaptics_rmi4_exp_fhandler*exp_fhandler;//structsynaptics_rmi4_data*rmi4_data=dev_get_drvdata(dev);----不能這樣取數(shù)據(jù)修改為://modifedbyjetinhuaqin,fordataerror.exeple:mutexdataerror,willcausesystemdeadlockstructinput_dev*input_raw=to_input_dev(dev);structsynaptics_rmi4_data*rmi4_data=input_get_drvdata(input_raw);4.工作隊列中能否使用等待隊列？？？FAQstaticintsynaptics_rmi4_set_input_dev(structsynaptics_rmi4_data*rmi4_data){intretval;inttemp;rmi4_data->input_dev=input_allocate_device();……………..input_set_drvdata(rmi4_data->input_dev,rmi4_data);是一個input設備類型}

staticintsynaptics_rmi4_resume(structdevice*dev){intretval;structsynaptics_rmi4_exp_fhandler*exp_fhandler;//structsynaptics_rmi4_data*rmi4_data=dev_get_drvdata(dev);----不能這樣取數(shù)據(jù)修改為://modifedbyjetinhuaqin,fordataerror.exeple:mutexdataerror,willcausesystemdeadlockstructinput_dev*input_raw=to_input_dev(dev);structsynaptics_rmi4_data*rmi4_data=input_get_drvdata(input_raw);4.工作隊列中能否使用等待隊列？？？FAQstaticvoid

hwmsen_work_func(structwork_struct*work){。。。。。。。。。。。。。#ifdefHQ_SENSORif((isCameraActive==1)&&((idx==ID_MOTION)||(idx==ID_LIGHT)||(idx==ID_PROXIMITY)||(idx==ID_FACE_DETECT))){HWM_ERR("donotreaddatafromsensor(%d)\n",idx);HWM_ERR("cameraisACTIVE,setthethreadintoWAITstatus\n");wait_event_interruptible(hi164_wq,(hi164_wq_flag==KAL_FALSE));//restarthi164toothermode5.軟中斷回調(diào)里面之后加mutexordeley等

會報出異常：比如內(nèi)核定時器里面使用mutex。：：軟中斷跑在swapper線程的內(nèi)核?？臻g：【c08bf890：c00119c4】]Backtrace:[52.113934](0)[0:swapper/0][<c00119c4>]save_stack_trace_tsk+0x0/0x98[52.113946](0)[0:swapper/0][<c03c7fc4>]aee_get_traces+0x60/0xc0[52.113957](0)[0:swapper/0][<c03c80b8>]aee_kernel_warning_api+0x94/0xe0[52.113970](0)[0:swapper