ioremap的疑惑

arm_zwinger

接觸linux不久，對ioremap的返回空間有些疑問。。。


環(huán)境arm, linux2.6
在設(shè)備上察看vmallocinfo，結(jié)果如下：

[root@FriendlyARM /proc]# cat vmallocinfo
0xc4808000-0xc480a000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc480c000-0xc480e000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4810000-0xc4812000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4814000-0xc4816000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4818000-0xc481a000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc481c000-0xc481e000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4820000-0xc4822000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4824000-0xc4826000    8192 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4a00000-0xc4b01000 1052672 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4c00000-0xc4d01000 1052672 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc4e00000-0xc4f01000 1052672 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc5000000-0xc5101000 1052672 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc5200000-0xc5301000 1052672 __arm_ioremap_pfn+0x78/0x330 ioremap
0xc5400000-0xc5501000 1052672 __arm_ioremap_pfn+0x78/0x330 ioremap
[root@FriendlyARM /proc]#

其中紅色部分，就是連續(xù)執(zhí)行了addr1=ioremap(0x20000000,4); addr2=ioremap(0x20000004,4);的結(jié)果。

問題：
1、個人理解，既然是只分配4個字節(jié)，那么ioremap返回一個page就夠了阿。為什么會返回8K空間（2個page）呢？
2、addr1和addr2分別是0xc4810000，0xc4814000。既然每個地址空間的分配只占了8K，那中間間隔的那8K呢，做什么用？比如從0xc4812000到0xc4814000這段空間，空閑著嗎？為什么不是連續(xù)分配給addr1和addr2呢？
3、實際上addr1和addr2 map的物理空間是連續(xù)的，那么如果訪問addr1+4是否就等于訪問addr2呢？

多謝各位！

arm_zwinger

大家都放假去了嗎？~

目前個人還是沒想明白，還請大家給個分析！

多謝！

linuxfellow

回復(fù) 1# arm_zwinger

先查查你的PAGE_SHIFT是多少？  會不會你的系統(tǒng)頁面大小就是8K？
   

arm_zwinger

不會啊，arm的頁面都是4K啊，而且查看相關(guān)的定義，PAGE_SHIFT是4K阿。。。
配置中，CONFIG_MMU也有定義。。。


/* PAGE_SHIFT determines the page size */
#define PAGE_SHIFT                12
#define PAGE_SIZE                (1UL << PAGE_SHIFT)
#define PAGE_MASK                (~(PAGE_SIZE-1))

瀚海書香

回復(fù) 1# arm_zwinger

1、個人理解，既然是只分配4個字節(jié)，那么ioremap返回一個page就夠了阿。為什么會返回8K空間（2個page）呢？
2、addr1和addr2分別是0xc4810000，0xc4814000。既然每個地址空間的分配只占了8K，那中間間隔的那8K呢，做什么用？比如從0xc4812000到0xc4814000這段空間，空閑著嗎？為什么不是連續(xù)分配給addr1和addr2呢？
3、實際上addr1和addr2 map的物理空間是連續(xù)的，那么如果訪問addr1+4是否就等于訪問addr2呢？

1. 這個問題從ioremap的源代碼中跟蹤一下，就可以看到了。ioremap--...-->__get_vm_area_node 在這個函數(shù)中，對所有的請求大小都加上一個PAGE_SIZE，用來作為一個gap使用，所以申請4個字節(jié)，對應(yīng)的實際大小就是 PAGE_ALIGN(4)+PAGE_SIZE = 8K
2. 這個應(yīng)該是隨機的，操作系統(tǒng)選擇一個可用的虛擬地址空間使用，不會刻意的去分隔開8K的，可能是這段地址空間恰好被使用了等等。
3. addr1+4K會進入gap，操作系統(tǒng)會捕獲這個異常的，不會訪問到另一個vm。

其實你的這個問題與ioremap關(guān)系不大，主要是VM部分的操作。

希望對你有幫助！

   

arm_zwinger

回復(fù) 5# 瀚海書香


萬分感謝！真是有求必應(yīng)！

對于問題2，我還是有些不解。
自己做了個測試：不停的ioremap，直到VM_END，系統(tǒng)會返回失敗，因為已經(jīng)到了最后的虛擬地址空間。程序判斷如果返回的地址是0xdeffe000或者0xdeffc000，那么就打印出來。結(jié)果發(fā)現(xiàn)只有0xdeffe000打印出來了，說明相連的8k（0xdeffc000)沒有被ioremap操作過。不清楚為什么要跨這8k，而且這8K也永遠不會被ioremap了。

一般系統(tǒng)也不會這么多的ioremap操作，可能是操作到了VM_END，就不再回頭找是否有空用的空間了？猜測而已。。。

不管怎樣，還是非常感謝“瀚海書香 ”！


   

瀚海書香

回復(fù) 6# arm_zwinger

對于問題2，我還是有些不解。
自己做了個測試：不停的ioremap，直到VM_END，系統(tǒng)會返回失敗，因為已經(jīng)到了最后的虛擬地址空間。程序判斷如果返回的地址是0xdeffe000或者0xdeffc000，那么就打印出來。結(jié)果發(fā)現(xiàn)只有0xdeffe000打印出來了，說明相連的8k（0xdeffc000)沒有被ioremap操作過。不清楚為什么要跨這8k，而且這8K也永遠不會被ioremap了。

我這邊在只有一個2410的板子是arm的，其他的都是X86的。我在這邊測試的情況是沒有出現(xiàn)你所說的問題。下面是在suse 11(x86_64)上的測試結(jié)果：
tingw:~/program/x86/kernel/ioremap # cat /proc/vmallocinfo > /root/info.old
tingw:~/program/x86/kernel/ioremap # insmod ioremap.ko
tingw:~/program/x86/kernel/ioremap # cat /proc/vmallocinfo > /root/info.new
tingw:~/program/x86/kernel/ioremap # diff /root/info.old /root/info.new
25a26,27
> 0xffffc90010232000-0xffffc90010234000    8192 hello_init+0x29/0x4c [ioremap] phys=14000 ioremap
> 0xffffc9001025e000-0xffffc90010260000    8192 hello_init+0x13/0x4c [ioremap] phys=12000 ioremap
47a50
> 0xffffffffa004e000-0xffffffffa0050000    8192 load_module+0x5f4/0x1130 pages=1 vmalloc N0=1

從輸出來看，vmalloc選擇應(yīng)該沒有刻意的預(yù)留固定的8K大小。

   

arm_zwinger

回復(fù) 7# 瀚海書香

從你的結(jié)果看起來，的確應(yīng)當(dāng)是OS自己選擇了一段vm去map的，看不出來有什么特別的規(guī)律。

難道是我這個版本的linux的實現(xiàn)上的問題？linux2.6.29.4

看來得再看看這個里面的實現(xiàn)。


   

東方云濱

學(xué)術(shù)氛圍很濃厚啊，受教了