本文目的
本文補充校正一些Linux內核開發者關于GFP_ATOMIC的認知不完整的地方,闡述GFP_ATOMIC與free內存watermark的關系,并明確什么時候應該用GFP_ATOMIC申請內存。目錄:
1. GFP_ATOMICvs. GFP_KERNEL
2. 內存水位,PF_MEMALLOC和GFP_ATOMIC
3. 何時使用GFP_ATOMIC(一個patch分析)
GFP_ATOMICvs. GFP_KERNEL
我們都知道,在中斷、軟中斷、spinlock等原子上下文里面,申請內存,應該使用GFP_ATOMIC標記,譬如內核中有大量的kmalloc/GFP_ATOMIC的例子:
對于不可睡眠的上下文,如果我們用常規的GFP_KERNEL這樣的標記去申請內存,可能引發直接的內存reclaim,從而引起睡眠,所以GFP_KERNEL這種標記只適合進程上下文調用:
GFP_KERNEL的標記可以引發直接的內存回收,從而導致進程阻塞睡眠,這在原子上下文顯然是不允許的。
#define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS) #define __GFP_RECLAIM ((__force gfp_t)(___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM)
內存水位,PF_MEMALLOC和GFP_ATOMIC
那么GFP_ATOMIC是否僅僅意味著不能睡眠呢?檔案是否定的,GFP_ATOMIC還與內存reclaim的水位相關。下面這個圖是講述水位watermark的一個著名的圖,筆者懶得畫了,直接從網下copy過來:
在Linux中,內存有3個水位:
HIGH:系統的free內存大于HIGH水位的時候,是一個相對保險的值,不需要急著做內存回收(reclaim);
LOW: 系統的free內存達到LOW水位的時候,啟動后臺kswapd進行內存回收,回收的目標是讓空閑內存達到HIGH水位;
MIN:系統應該保有的最小free內存,當空閑內存達到這個值的時候,kswapd的后臺回收可能來不及了,一般用戶在申請內存的時候,進行DIRECT RECLAIM。
min水位一般是系統自動換算的,其具體值可以從/proc看出:
# cat /proc/sys/vm/min_free_kbytes 45056
而LOW水位一般是min*125%,HIGH 一般是min*150%。
MIN水位以下的內存,只能被緊急情況下的用戶申請到,最著名的緊急用戶莫過于PF_MEMALLOC用戶,task_struct設置了這個標記表示忽略MIN水位。比如回收內存的代碼本身也可能需要申請內存,這個時候我們應該給它無限制的申請能力。典型地,比如kswapd就設置了這個標記,這個代碼里面的注釋也非常精彩:
如果我們不允許回收內存的代碼申請min以下的內存,則回收內存的代碼可以觸發回收內存,這樣“子子孫孫,無窮匱也”。
當然,PF_MEMALLOC不是唯一的緊急用戶,GFP_ATOMIC實際也是一個“半緊急”任務:
說它“緊急”,是因為如果原子上下文申請內存失敗,往往意味著相應的中斷、軟中斷、spinlock內部的代碼就會執行失敗,而我們又不會因為這種失敗,而去嘗試內存回收,這顯然比較慘,我們應該盡可能讓GFP_ATOMIC申請成功;
說它“半”,是因為它不至于緊急到PF_MEMALLOC這個程度,如果我們給它無限地申請到free內存為0的權力,則會導致PF_MEMALLOC沒有內存了。想想,如果征糧隊的人都餓死了,還怎么去征糧呢?
所以,內存的設計選擇是,當有人用GFP_ATOMIC申請內存的時候,允許它從MIN水位以下,申請一定數量的內存。什么叫“一定數量”呢?就是不能讓GFP_ATOMIC導致free 內存觸底,GFP_ATOMIC還包含了高優先級的含義:
#define GFP_ATOMIC (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)
注意這個里面的__GFP_HIGH不是HIGHMEM高端內存的意思,而是高優先級。
當我們用GFP_ATOMIC申請內存的時候,內核的水位檢查代碼,會允許我們觸及到MIN水位以下的1/2:
那么,“魔鬼”就是在畫紅圈的2行代碼。但是,如果我們進一步深究,會發現,GFP_ATOMIC不只是觸及1/2*min,它甚至可以觸及1/4*min,因為GFP_ATOMIC中的__GFP_HIGH讓ALLOC_HIGH成立,而__GFP_ATOMIC讓ALLOC_HARDER成立:
所以,“魔鬼”又隱藏在了gfp_to_alloc_flags()的細節里。
一個patch的例子
在具體的工程實戰中,我們建議:
原子上下文使用GFP_ATOMIC
比如在網絡設備驅動drivers/net/ethernet中,就有大量的案例
在內存緊急的路徑上(比如不想睡眠,要求低延遲;或者要求內存吃緊的情況下,仍然可以從min水位以下申請內存),哪怕是進程上下文,我們也建議可以考慮使用GFP_ATOMIC
比如田濤童鞋最近在mm/zswap.c發的RFC patch:
https://lore.kernel.org/linux-mm/1608894171-54174-2-git-send-email-tiantao6@hisilicon.com/
上面2個地方,其實都是可以睡眠的進程上下文,但是我們認為在frontendswap的路徑上,我們對延遲敏感,對swap內存過程中進一步引發內存回收也擔憂,因此,這里哪怕是非原子上下文,我們也沒有使用GFP_KERNEL。
責任編輯:xj
原文標題:宋寶華:Linux內核中用GFP_ATOMIC申請內存究竟意味著什么?
文章出處:【微信公眾號:Linuxer】歡迎添加關注!文章轉載請注明出處。
-
內核
+關注
關注
3文章
1372瀏覽量
40298 -
Linux
+關注
關注
87文章
11310瀏覽量
209601 -
GFP
+關注
關注
0文章
5瀏覽量
1417
原文標題:宋寶華:Linux內核中用GFP_ATOMIC申請內存究竟意味著什么?
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論