LINUX內核經(jīng)典面試題_第1頁
LINUX內核經(jīng)典面試題_第2頁
LINUX內核經(jīng)典面試題_第3頁
LINUX內核經(jīng)典面試題_第4頁
LINUX內核經(jīng)典面試題_第5頁
已閱讀5頁,還剩4頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、LINUX內核經(jīng)典面試題 2015-05-02 23:08:14分類: LINUX原文地址:LINUX內核經(jīng)典面試題 作者:sunjiangang-ok1) Linux中主要有哪幾種內核鎖?2) Linux中的用戶模式和內核模式是什么含意?3) 怎樣申請大塊內核內存?4) 用戶進程間通信主要哪幾種方式?5) 通過伙伴系統(tǒng)申請內核內存的函數(shù)有哪些?6) 通過slab分配器申請內核內存的函數(shù)有?7) Linux的內核空間和用戶空間是如何劃分的(以32位系統(tǒng)為例)?8) vmalloc()申請的內存有什么特點?9) 用戶程序使用malloc()申請到的內存空間在什么范圍

2、?10) 在支持并使能MMU的系統(tǒng)中,Linux內核和用戶程序分別運行在物理地址模式還是虛擬地址模式?11) ARM處理器是通過幾級也表進行存儲空間映射的?12) Linux是通過什么組件來實現(xiàn)支持多種文件系通的?13) Linux虛擬文件系統(tǒng)的關鍵數(shù)據(jù)結構有哪些?(至少寫出四個)14) 對文件或設備的操作函數(shù)保存在那個數(shù)據(jù)結構中?15) Linux中的文件包括哪些?16) 創(chuàng)建進程的系統(tǒng)調用有那些?17) 調用schedule()進行進程切換的方式有幾種?18) Linux調度程序是根據(jù)進程的動態(tài)優(yōu)先級還是靜態(tài)優(yōu)先級來調度進程的?19) 進程調度的核心數(shù)據(jù)結構是哪個?20) 如何加載、卸載一

3、個模塊?21) 模塊和應用程序分別運行在什么空間?22) Linux中的浮點運算由應用程序實現(xiàn)還是內核實現(xiàn)?23) 模塊程序能否使用可鏈接的庫函數(shù)?24) TLB中緩存的是什么內容?25) Linux中有哪幾種設備?26) 字符設備驅動程序的關鍵數(shù)據(jù)結構是哪個?27) 設備驅動程序包括哪些功能函數(shù)?28) 如何唯一標識一個設備?29) Linux通過什么方式實現(xiàn)系統(tǒng)調用?30) Linux軟中斷和工作隊列的作用是什么?1.     Linux中主要有哪幾種內核鎖?Linux的同步機制從2.0到2.6以來不斷發(fā)展完善。從最初的原子操作,到后來的信

4、號量,從大內核鎖到今天的自旋鎖。這些同步機制的發(fā)展伴隨Linux從單處理器到對稱多處理器的過渡;伴隨著從非搶占內核到搶占內核的過度。Linux的鎖機制越來越有效,也越來越復雜。Linux的內核鎖主要是自旋鎖和信號量。自旋鎖最多只能被一個可執(zhí)行線程持有,如果一個執(zhí)行線程試圖請求一個已被爭用(已經(jīng)被持有)的自旋鎖,那么這個線程就會一直進行忙循環(huán)旋轉等待鎖重新可用。要是鎖未被爭用,請求它的執(zhí)行線程便能立刻得到它并且繼續(xù)進行。自旋鎖可以在任何時刻防止多于一個的執(zhí)行線程同時進入臨界區(qū)。Linux中的信號量是一種睡眠鎖。如果有一個任務試圖獲得一個已被持有的信號量時,信號量會將其推入等待隊列,然后讓其睡眠。

5、這時處理器獲得自由去執(zhí)行其它代碼。當持有信號量的進程將信號量釋放后,在等待隊列中的一個任務將被喚醒,從而便可以獲得這個信號量。信號量的睡眠特性,使得信號量適用于鎖會被長時間持有的情況;只能在進程上下文中使用,因為中斷上下文中是不能被調度的;另外當代碼持有信號量時,不可以再持有自旋鎖。Linux 內核中的同步機制:原子操作、信號量、讀寫信號量和自旋鎖的API,另外一些同步機制,包括大內核鎖、讀寫鎖、大讀者鎖、RCU (Read-Copy Update,顧名思義就是讀-拷貝修改),和順序鎖。2.     Linux中的用戶模式和

6、內核模式是什么含意?MS-DOS等操作系統(tǒng)在單一的CPU模式下運行,但是一些類Unix的操作系統(tǒng)則使用了雙模式,可以有效地實現(xiàn)時間共享。在Linux機器上,CPU要么處于受信任的內核模式,要么處于受限制的用戶模式。除了內核本身處于內核模式以外,所有的用戶進程都運行在用戶模式之中。內核模式的代碼可以無限制地訪問所有處理器指令集以及全部內存和I/O空間。如果用戶模式的進程要享有此特權,它必須通過系統(tǒng)調用向設備驅動程序或其他內核模式的代碼發(fā)出請求。另外,用戶模式的代碼允許發(fā)生缺頁,而內核模式的代碼則不允許。在2.4和更早的內核中,僅僅用戶模式的進程可以被上下文切換出局,由其他進程搶占。除非發(fā)生以下兩

7、種情況,否則內核模式代碼可以一直獨占CPU:(1) 它自愿放棄CPU;(2) 發(fā)生中斷或異常。2.6內核引入了內核搶占,大多數(shù)內核模式的代碼也可以被搶占。3.     怎樣申請大塊內核內存?在Linux內核環(huán)境下,申請大塊內存的成功率隨著系統(tǒng)運行時間的增加而減少,雖然可以通過vmalloc系列調用申請物理不連續(xù)但虛擬地址連續(xù)的內存,但畢竟其使用效率不高且在32位系統(tǒng)上vmalloc的內存地址空間有限。所以,一般的建議是在系統(tǒng)啟動階段申請大塊內存,但是其成功的概率也只是比較高而已,而不是100%。如果程序真的比較在意這個申請的

8、成功與否,只能退用“啟動內存”(Boot Memory)。下面就是申請并導出啟動內存的一段示例代碼:void* x_bootmem = NULL;EXPORT_SYMBOL(x_bootmem);unsigned long x_bootmem_size = 0;EXPORT_SYMBOL(x_bootmem_size);static int _init x_bootmem_setup(char *str)       

9、0;x_bootmem_size = memparse(str, &str);        x_bootmem = alloc_bootmem(x_bootmem_size);        printk("Reserved %lu bytes from %p for xn", x_bootmem_size, x_bootmem);

10、60;       return 1;_setup("x-bootmem=", x_bootmem_setup);可見其應用還是比較簡單的,不過利弊總是共生的,它不可避免也有其自身的限制:內存申請代碼只能連接進內核,不能在模塊中使用。被申請的內存不會被頁分配器和slab分配器所使用和統(tǒng)計,也就是說它處于系統(tǒng)的可見內存之外,即使在將來的某個地方你釋放了它。一般用戶只會申請一大塊內存,如果需要在其上實現(xiàn)復雜的內存管理則需要自己實現(xiàn)。在不允許內存分配失敗的場合,通過啟動內存預留內存空間將是我

11、們唯一的選擇。4.   用戶進程間通信主要哪幾種方式?(1)管道(Pipe):管道可用于具有親緣關系進程間的通信,允許一個進程和另一個與它有共同祖先的進程之間進行通信。(2)命名管道(named pipe):命名管道克服了管道沒有名字的限制,因此,除具有管道所具有的功能外,它還允許無親緣關系進程間的通信。命名管道在文件系統(tǒng)中有對應的文件名。命名管道通過命令mkfifo或系統(tǒng)調用mkfifo來創(chuàng)建。(3)信號(Signal):信號是比較復雜的通信方式,用于通知接受進程有某種事件發(fā)生,除了用于進程間通信外,進程還可以發(fā)送信號給進程本身;linux除了支持Unix早期信

12、號語義函數(shù)sigal外,還支持語義符合Posix.1標準的信號函數(shù)sigaction(實際上,該函數(shù)是基于BSD的,BSD為了實現(xiàn)可靠信號機制,又能夠統(tǒng)一對外接口,用sigaction函數(shù)重新實現(xiàn)了signal函數(shù))。(4)消息(Message)隊列:消息隊列是消息的鏈接表,包括Posix消息隊列system V消息隊列。有足夠權限的進程可以向隊列中添加消息,被賦予讀權限的進程則可以讀走隊列中的消息。消息隊列克服了信號承載信息量少,管道只能承載無格式字節(jié)流以及緩沖區(qū)大小受限等缺(5)共享內存:使得多個進程可以訪問同一塊內存空間,是最快的可用IPC形式。是針對其他通信機制運行效率較低而設計的。往

13、往與其它通信機制,如信號量結合使用,來達到進程間的同步及互斥。(6)信號量(semaphore):主要作為進程間以及同一進程不同線程之間的同步手段。(7)套接字(Socket):更為一般的進程間通信機制,可用于不同機器之間的進程間通信。起初是由Unix系統(tǒng)的BSD分支開發(fā)出來的,但現(xiàn)在一般可以移植到其它類Unix系統(tǒng)上:Linux和System V的變種都支持套接字。5.     通過伙伴系統(tǒng)申請內核內存的函數(shù)有哪些?在物理頁面管理上實現(xiàn)了基于區(qū)的伙伴系統(tǒng)(zone based buddy system)。對不同區(qū)的內存使用單獨的伙伴系統(tǒng)(bu

14、ddy system)管理,而且獨立地監(jiān)控空閑頁。相應接口alloc_pages(gfp_mask, order),_ _get_free_pages(gfp_mask, order)等。補充知識:1.原理說明Linux內核中采 用了一種同時適用于32位和64位系統(tǒng)的內 存分頁模型,對于32位系統(tǒng)來說,兩級頁表足夠用了,而在x86_64系 統(tǒng)中,用到了四級頁表。* 頁全局目錄(Page Global Directory)* 頁上級目錄(Page Upper Directory)* 頁中間目錄(Page Middle Directory

15、)* 頁表(Page Table)頁全局目錄包含若干頁上級目錄的地址,頁上級目錄又依次包含若干頁中間目錄的地址,而頁中間目錄又包含若干頁表的地址,每一個頁表項指 向一個頁框。Linux中采用4KB大小的 頁框作為標準的內存分配單元。多級分頁目錄結構1.1.伙伴系統(tǒng)算法在實際應用中,經(jīng)常需要分配一組連續(xù)的頁框,而頻繁地申請和釋放不同大小的連續(xù)頁框,必然導致在已分配頁框的內存塊中分散了許多小塊的 空閑頁框。這樣,即使這些頁框是空閑的,其他需要分配連續(xù)頁框的應用也很難得到滿足。為了避免出現(xiàn)這種情況,Linux內核中引入了伙伴系統(tǒng)算法(buddy system)

16、。把所有的空閑頁框分組為11個 塊鏈表,每個塊鏈表分別包含大小為1,2,4,8,16,32,64,128,256,512和1024個連續(xù)頁框的頁框塊。最大可以申請1024個連 續(xù)頁框,對應4MB大小的連續(xù)內存。每個頁框塊的第一個頁框的物理地址是該塊大小的整數(shù)倍。假設要申請一個256個頁框的塊,先從256個頁框的鏈表中查找空閑塊,如果沒有,就去512個 頁框的鏈表中找,找到了則將頁框塊分為2個256個 頁框的塊,一個分配給應用,另外一個移到256個頁框的鏈表中。如果512個頁框的鏈表中仍沒有空閑塊,繼續(xù)向1024個頁 框的鏈表查找,如果仍然沒有,

17、則返回錯誤。頁框塊在釋放時,會主動將兩個連續(xù)的頁框塊合并為一個較大的頁框塊。1.2.slab分配器slab分配器源于 Solaris 2.4 的 分配算法,工作于物理內存頁框分配器之上,管理特定大小對象的緩存,進行快速而高效的內存分配。slab分配器為每種使用的內核對象建立單獨的緩沖區(qū)。Linux 內核已經(jīng)采用了伙伴系統(tǒng)管理物理內存頁框,因此 slab分配器直接工作于伙伴系 統(tǒng)之上。每種緩沖區(qū)由多個 slab 組成,每個 slab就是一組連續(xù)的物理內存頁框,被劃分成了固定數(shù)目的對象。根據(jù)對象大小的不同,缺

18、省情況下一個 slab 最多可以由 1024個頁框構成。出于對齊 等其它方面的要求,slab 中分配給對象的內存可能大于用戶要求的對象實際大小,這會造成一定的 內存浪費。2.常用內存分配函數(shù)2.1._get_free_pagesunsigned long _get_free_pages(gfp_t gfp_mask, unsigned int order)_get_free_pages函數(shù)是最原始的內存分配方式,直接從伙伴系統(tǒng)中獲取原始頁框,返回值為第一個頁框的起始地址。_get_free_pages在實現(xiàn)上只是封裝了alloc_pa

19、ges函 數(shù),從代碼分析,alloc_pages函數(shù)會分配長度為1<2.2.kmem_cache_allocstruct kmem_cache *kmem_cache_create(const char *name, size_t size,size_t align, unsigned long flags,void (*ctor)(void*, struct kmem_cache *, unsigned long),void (*dtor)(void*, struct kmem_cache *, unsigned long)void *kmem_cache_alloc(str

20、uct kmem_cache *c, gfp_t flags)kmem_cache_create/ kmem_cache_alloc是基于slab分配器的一種內存分配方式,適用于反復分配釋放同一大小內存塊的場合。首先用kmem_cache_create創(chuàng)建一個高速緩存區(qū)域,然后用kmem_cache_alloc從 該高速緩存區(qū)域中獲取新的內存塊。kmem_cache_alloc一次能分配的最大內存由mm/slab.c文件中的MAX_OBJ_ORDER宏定義,在默認的2.6.18內核版本中,該宏定義為5, 于是一次最多能申請1<<5 * 4KB也就是128KB的&

21、#160;連續(xù)物理內存。分析內核源碼發(fā)現(xiàn),kmem_cache_create函數(shù)的size參數(shù)大于128KB時會調用BUG()。測試結果驗證了分析結果,用kmem_cache_create分 配超過128KB的內存時使內核崩潰。2.3.kmallocvoid *kmalloc(size_t size, gfp_t flags)kmalloc是內核中最常用的一種內存分配方式,它通過調用kmem_cache_alloc函數(shù)來實現(xiàn)。kmalloc一次最多能申請的內存大小由include/linux/Kmalloc_size.h的 內容來決定,在默認的2.6.18內核版本中,kma

22、lloc一 次最多能申請大小為131702B也就是128KB字 節(jié)的連續(xù)物理內存。測試結果表明,如果試圖用kmalloc函數(shù)分配大于128KB的內存,編譯不能通過。2.4.vmallocvoid *vmalloc(unsigned long size)前面幾種內存分配方式都是物理連續(xù)的,能保證較低的平均訪問時間。但是在某些場合中,對內存區(qū)的請求不是很頻繁,較高的內存訪問時間也 可以接受,這是就可以分配一段線性連續(xù),物理不連續(xù)的地址,帶來的好處是一次可以分配較大塊的內存。圖3-1表 示的是vmalloc分配的內存使用的地址范圍。vmalloc對 

23、一次能分配的內存大小沒有明確限制。出于性能考慮,應謹慎使用vmalloc函數(shù)。在測試過程中, 最大能一次分配1GB的空間。Linux內核部分內存分布2.5.dma_alloc_coherentvoid *dma_alloc_coherent(struct device *dev, size_t size,ma_addr_t *dma_handle, gfp_t gfp)DMA是一種硬件機制,允許外圍設備和主存之間直接傳輸IO數(shù)據(jù),而不需要CPU的參與,使用DMA機制能大幅提高與設備通信的 吞吐量。DMA操作中,涉及到CPU高速緩 存和對應的內存數(shù)據(jù)一致性的問題,必

24、須保證兩者的數(shù)據(jù)一致,在x86_64體系結構中,硬件已經(jīng)很 好的解決了這個問題,dma_alloc_coherent和_get_free_pages函數(shù)實現(xiàn)差別不大,前者實際是調用_alloc_pages函 數(shù)來分配內存,因此一次分配內存的大小限制和后者一樣。_get_free_pages分配的內 存同樣可以用于DMA操作。測試結果證明,dma_alloc_coherent函 數(shù)一次能分配的最大內存也為4M。2.6.ioremapvoid * ioremap (unsigned long offset, unsigned long size)iorema

25、p是一種更直接的內存“分配”方式,使用時直接指定物理起始地址和需要分配內存的大小,然后將該段 物理地址映射到內核地址空間。ioremap用到的物理地址空間都是事先確定的,和上面的幾種內存 分配方式并不太一樣,并不是分配一段新的物理內存。ioremap多用于設備驅動,可以讓CPU直接訪問外部設備的IO空間。ioremap能映射的內存由原有的物理內存空間決定,所以沒有進行測試。 2.7.Boot Memory如果要分配大量的連續(xù)物理內存,上述的分配函數(shù)都不能滿足,就只能用比較特殊的方式,在Linux內 核引導階段來預留部分內存。2.7.1.在內核引導時分配內

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論