91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內(nèi)不再提示

什么是內(nèi)存管理?如何進行內(nèi)存管理?及內(nèi)存管理的方案與分析

Q4MP_gh_c472c21 ? 來源:嵌入式云IOT技術圈 ? 作者:嵌入式云IOT技術圈 ? 2021-03-26 13:38 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

前面已經(jīng)將所有的硬件驅(qū)動實現(xiàn),驗證了硬件功能。但是每一個硬件都是單獨測試的,而且并不完善。下一步,我們需要對各個驅(qū)動進行整合完善。在整合之前,需要做一些基礎工作。其中之一就是實現(xiàn)內(nèi)存管理。什么叫內(nèi)存管理呢?為什么要做內(nèi)存管理?前面我們已經(jīng)大概了解了程序中的變量現(xiàn)在我們復習一下:局部變量、全局變量。

局部變量在進入函數(shù)時從??臻g分配,退出函數(shù)前釋放。全局變量則在整個程序運行其中一直使用。在程序編譯時就已經(jīng)分配了RAM空間。

那還有沒有第三種變量呢?可以說沒有。但是如果從生存周期上看,是有的:一個變量,在多個函數(shù)內(nèi)使用,但是又不是整個程序運行期間都使用。或:一個變量,在一段時間內(nèi)使用,不是整個程序運行生命周期都要用,但是用這個變量的函數(shù)會退出,然后重復進入(用static定義的局部變量相當于全局變量)

如果不使用動態(tài)內(nèi)存管理,這樣的變量就只能定義為全局變量。如果將這些變量定義為指針,當要使用時,通過內(nèi)存管理分配,使用完后就釋放,這就叫做動態(tài)分配。舉個實際的例子:

一個設備,有三種通信方式:串口,USB,網(wǎng)絡,在通信過程每個通信方式需要1K RAM。經(jīng)過分析,3種通信方式不會同時使用。那么,如果不使用動態(tài)內(nèi)存,則需要3K變量。如果使用內(nèi)存管理動態(tài)分配,則只需要1K內(nèi)存就可以了。(這個只是舉例,如果簡單的系統(tǒng),確定三種方式不同時使用,可以直接復用內(nèi)存)

通信方式只是舉例,其實一個系統(tǒng)中,并不是所有設備都一直使用,如果使用動態(tài)內(nèi)存管理,RAM的峰值用量將會大大減少。

內(nèi)存管理方案

不發(fā)明車輪,只優(yōu)化輪胎。

內(nèi)存管理是編程界的一個大話題,有很多經(jīng)典的方案。很多人也在嘗試寫新的方案。內(nèi)存分配模塊我們使用K&R C examples作為基礎,然后進行優(yōu)化。K&R是誰?就是寫《C程序設計語言》的兩個家伙。如果你沒有這本書,真遺憾。這本書的8.7章節(jié),《實例--存儲分配程序》,介紹了一種基本的存儲分配方法。代碼見alloc.c,整個代碼只有120行,而且結構很美。

K&R 內(nèi)存管理方案分析

下面我們結合代碼分析這種內(nèi)存分配方案。代碼在wujiqueUtilitiesalloc文件夾。

內(nèi)存分析

初始化

在malloc函數(shù)中,如果是第一次調(diào)用就會初始化內(nèi)存鏈表。代碼原來是通過獲取堆地址,在堆上建立內(nèi)存池。我們把他改為更直觀的數(shù)組定義方式。內(nèi)存建立后的內(nèi)存視圖如下:

27ce31e6-8dcc-11eb-8b86-12bb97331649.png

內(nèi)存分配的最小單元是:

typedef struct ALLOC_HDR{ struct{ struct ALLOC_HDR *ptr; unsigned int size;/*本塊內(nèi)存容量*/} s; unsigned int align; unsigned int pad;} ALLOC_HDR;

這也就是內(nèi)存管理結構體。在32位ARM系統(tǒng)上,這個結構體是16字節(jié)。

第一次分配

每次分配,就是在一塊可以分配的空間尾部切割一塊出來,切割的大小是16字節(jié)的倍數(shù),而且會比需要的內(nèi)存多一塊頭。這塊頭在內(nèi)存釋放時需要使用。這一塊,也就是內(nèi)存管理的開銷。

27fe35f8-8dcc-11eb-8b86-12bb97331649.png

分配釋放后

經(jīng)過多次分配釋放后,內(nèi)存可能如下圖,綠色是兩塊不連續(xù)的空閑塊,黃色是分配出去的塊。分配出去的塊,已經(jīng)不在內(nèi)存鏈表里面。

283eaa8e-8dcc-11eb-8b86-12bb97331649.png

缺點

一般情況上面的代碼已經(jīng)能滿足需求。但是,有以下缺陷:

缺點1:容易碎片化

分配使用首次適應法,也即是找到一塊大于等于要分配內(nèi)存的空閑塊,立刻進行分配。這種方法的優(yōu)點是速度較快,缺點是容易內(nèi)存碎片化,分配時將很多大塊內(nèi)存切割成小內(nèi)存了。經(jīng)過多次分配后,很可能出現(xiàn)以下情況:

空閑內(nèi)存總量還有10K,但是卻被分散在10個塊內(nèi),而且沒有大容量的內(nèi)存塊,再申請2K內(nèi)存就出現(xiàn)失敗。如果對時間并不是那么敏感,我們可以使用最適合法,也即是遍歷空閑鏈表,查找一個最合適的內(nèi)存(大于要分配內(nèi)存且容量最小的空閑塊),減少大內(nèi)存被切碎的概率。需要注意的是,最適合法,除了會增加分配時間,不會減少內(nèi)存碎片數(shù)量,只是增加了空閑內(nèi)存的集中度。假設經(jīng)過多次分配后,空閑總量還是10K,也是分散在10個空閑塊,但是在這10個空閑塊中,會有5K的大塊,再申請2K的時候,就可以申請到2K內(nèi)存了。

缺點2:內(nèi)存消耗

內(nèi)存分配方案使用了一個結構體,每次分配的最小單位就是這個結構體的大小16字節(jié)。

typedef struct ALLOC_HDR{ struct{ struct ALLOC_HDR *ptr; unsigned int size;/*本塊內(nèi)存容量*/} s; unsigned int align; unsigned int pad;} ALLOC_HDR;

一次分配,最少就是2個結構體(一個結構體用于管理分配出去的內(nèi)存,其余結構體做為申請內(nèi)存),也就是32字節(jié)。如果代碼有大量小內(nèi)存申請,例如申請100次8個字節(jié)

需求內(nèi)存:100X8=800字節(jié)實際消耗內(nèi)存100X32 = 3200字節(jié)利用率只有800/3200 =25%

如果內(nèi)存分配只有25%的使用率,對于小內(nèi)存嵌入式設備來說,是致命的方案缺陷。

如何解決呢?我們可以參考LINUX內(nèi)存分配方案SLAB。在LINUX中,有很多模塊需要申請固定大小的內(nèi)存(例如node結構體),為了加快分配速度,系統(tǒng)會使用malloc先從大內(nèi)存池中申請一批node結構體大小的內(nèi)存,作為一個slab內(nèi)存池。當需要分配node結構體時,就直接從slab內(nèi)存池申請。同理,可以將內(nèi)存分配優(yōu)化為:需要小內(nèi)存時,從大塊內(nèi)存池分配一塊大內(nèi)存,例如512,使用新算法管理,用于小內(nèi)存分配。當512消耗盡,再從大內(nèi)存池申請第二塊512字節(jié)大內(nèi)存。當小內(nèi)存釋放時,判斷小塊內(nèi)存池是否為空,如為空,將小塊內(nèi)存池釋放回大內(nèi)存池。那如何管理這個小內(nèi)存池呢?

缺點3:沒有管理已分配內(nèi)存

內(nèi)存分配沒有將已分配內(nèi)存管理起來。我們可以對已分配內(nèi)存進行統(tǒng)一管理:

1 已分配內(nèi)存在頭部有原來的結構體,通過ptr指針,將所有已分配內(nèi)存連接在已分配鏈表上。2 利用不使用的align跟pad成員,記錄分配時間跟分配對象(記錄哪個驅(qū)動申請的內(nèi)存)

通過上面優(yōu)化后,就可以統(tǒng)計已經(jīng)分配了多少內(nèi)存,還有多少空閑內(nèi)存,哪個模塊申請了最多內(nèi)存等數(shù)據(jù)。

使用

1 將代碼中的所有free改為為wjq_free,malloc改為wjq_malloc。

串口緩沖用了free跟malloc.fatfs的syscall.c 用了lwip的mem.h用了。

2 修改啟動代碼, 棧跟堆改小。不用庫的malloc,堆可以完全不要。棧,還是要保留,但是不需要那么大,如果函數(shù)內(nèi)用到比較大的局部變量,改為動態(tài)申請。

Stack_Size EQU 0x00002000

AREA STACK, NOINIT, READWRITE, ALIGN=3Stack_Mem SPACE Stack_Size__initial_sp

; 《h》 Heap Configuration; 《o》 Heap Size (in Bytes) 《0x0-0xFFFFFFFF:8》; 《/h》

Heap_Size EQU 0x00000010

AREA HEAP, NOINIT, READWRITE, ALIGN=3__heap_baseHeap_Mem SPACE Heap_Size__heap_limit

3 內(nèi)存池開了80K,編譯不過

linking.。..Objectswujique.axf: Error: L6406E: No space in execution regions with .ANY selector matching dev_touchscreen.o(.bss)。.Objectswujique.axf: Error: L6406E: No space in execution regions with .ANY selector matching mcu_uart.o(.bss)。.Objectswujique.axf: Error: L6406E: No space in execution regions with .ANY selector matching etharp.o(.bss)。.Objectswujique.axf: Error: L6406E: No space in execution regions with .ANY selector matching mcu_can.o(.bss)。.Objectswujique.axf: Error: L6406E: No space in execution regions with .ANY selector matching netconf.o(.bss)。先把內(nèi)存池改小,編譯通過之后,分析 map文件,用了較多全局變量的統(tǒng)統(tǒng)改小或者改為動態(tài)申請。分析map文件,還可以檢查還有沒有使用庫里面的malloc。Code (inc. data) RO Data RW Data ZI Data Debug Object Name 124 32 0 4 40976 1658 alloc.o 16 0 0 0 0 2474 def.o 96 34 8640 4 0 1377 dev_dacsound.o 300 36 0 0 0 2751 dev_esp8266.o 204 38 0 1 0 1446 dev_key.o 436 98 0 10 16 3648 dev_touchkey.o 310 18 0 14 3000 3444 dev_touchscreen.o 932 18 0 4 0 15981 dhcp.o 0 0 0 0 3964 5933 dual_func_demo.o 280 14 12 0 200 5963 etharp.o 0 0 0 0 0 35864 ethernetif.o 0 0 0 0 0 3820 inet.o 98 0 0 0 0 2022 inet_chksum.o 0 0 0 0 0 4163 init.o 168 4 0 20 0 4763 ip.o 0 0 4 0 0 6463 ip_addr.o 386 4 0 0 0 4118 ip_frag.o 264 38 0 8 16 383399 main.o 84 8 0 0 0 1410 mcu_adc.o 60 32 0 1 68 1511 mcu_can.o 12 0 0 0 0 521 mcu_dac.o 128 14 0 0 0 2352 mcu_i2c.o 28 8 0 1 0 630 mcu_i2s.o 336 92 0 0 0 2689 mcu_rtc.o 430 86 0 1 0 4396 mcu_timer.o 1564 82 0 0 328 9072 mcu_uart.o 504 20 0 12 0 4510 mem.o 56 10 0 0 9463 3250 memp.o 120 14 0 0 0 1651 misc.o 0 0 0 0 56 1066 netconf.o 118 0 0 0 0 4267 netif.o 684 0 0 0 0 6971 pbuf.o 36 8 392 0 8192 824 startup_stm32f40_41xxx.o

alloc.o 內(nèi)存池dev_touchscreen.o 觸摸屏緩沖dual_func_demo.o USB,應該能優(yōu)化memp.o 什么鬼?又一個內(nèi)存池?應該是要優(yōu)化掉startup_stm32f40_41xxx.o 啟動代碼,是棧跟堆用的RAM.

由于編譯器的優(yōu)化,項目沒用到的代碼沒有編譯進來,上面的map數(shù)據(jù)并不完整。等后面我們做完全部測試程序,所有用到的代碼都會參與連接,到時還需要優(yōu)化一次。

總結

內(nèi)存管理暫時到此,等后面所有功能都完成后,再進行一次優(yōu)化。如果對內(nèi)存分配時間有更高要求,可使用伙伴內(nèi)存分配法。
編輯:lyn

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 代碼
    +關注

    關注

    30

    文章

    4968

    瀏覽量

    74001
  • 內(nèi)存管理

    關注

    0

    文章

    171

    瀏覽量

    14886

原文標題:深度:產(chǎn)品級的MCU是如何進行內(nèi)存管理的?

文章出處:【微信號:gh_c472c2199c88,微信公眾號:嵌入式微處理器】歡迎添加關注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    MangoTree Halo Ultra「全新PXI」,標配自動糾錯內(nèi)存#

    內(nèi)存
    芒果樹數(shù)字
    發(fā)布于 :2026年03月06日 15:59:34

    Redis內(nèi)存管理、持久化策略與慢查詢排查分析

    Redis 在生產(chǎn)環(huán)境中承擔著緩存、會話存儲、消息隊列、分布式鎖等多種角色。隨著數(shù)據(jù)量增長和并發(fā)壓力上升,內(nèi)存碎片、持久化 I/O 抖動、慢查詢堆積這三類問題會逐漸顯現(xiàn),直接影響服務延遲和穩(wěn)定性。Redis 8.x 在內(nèi)存管理
    的頭像 發(fā)表于 02-27 11:00 ?147次閱讀

    探秘DS2731:緩存內(nèi)存電池備份管理IC的卓越性能與應用

    備份管理IC——MAXIM DS2731。 文件下載: DS2731.pdf 一、DS2731簡介 DS2731是一款專為模塊化備份應用而設計的完整電源管理解決方案,特別適用于2.5V及以下的內(nèi)存總線電壓,其輸入電壓為12V。它
    的頭像 發(fā)表于 02-24 16:40 ?324次閱讀

    rk基于linux/android內(nèi)存管理

    一、內(nèi)存分布 ? U-Boot 由前級 Loader 加載到 CONFIG_SYS_TEXT_BASE 地址,初始化時會探明當前系統(tǒng)的總內(nèi)存容 量, 32 位平臺上認為最大 4GB 可用(但是不影響
    的頭像 發(fā)表于 12-15 10:42 ?217次閱讀
    rk基于linux/android<b class='flag-5'>內(nèi)存</b><b class='flag-5'>管理</b>

    WebGL/Canvas 內(nèi)存泄露分析

    在構建高性能、長周期運行的 WebGL/Canvas 應用(如 3D 編輯器、數(shù)據(jù)可視化平臺)時,內(nèi)存管理是一個至關重要且極具挑戰(zhàn)性的課題。 開發(fā)者通常面臨的內(nèi)存泄漏問題,其根源遠比簡單
    的頭像 發(fā)表于 10-21 11:40 ?418次閱讀
    WebGL/Canvas <b class='flag-5'>內(nèi)存</b>泄露<b class='flag-5'>分析</b>

    靈活高效ZBUFF — C內(nèi)存數(shù)據(jù)操作庫:優(yōu)化內(nèi)存管理的利器

    在C語言開發(fā)中,高效的內(nèi)存管理是提升程序性能的關鍵。ZBUFF作為一款靈活高效的內(nèi)存數(shù)據(jù)操作庫,通過優(yōu)化內(nèi)存分配與釋放機制,為開發(fā)者提供了更簡潔、更安全的API接口,極大地簡化了復雜數(shù)
    的頭像 發(fā)表于 08-14 18:01 ?697次閱讀
    靈活高效ZBUFF — C<b class='flag-5'>內(nèi)存</b>數(shù)據(jù)操作庫:優(yōu)化<b class='flag-5'>內(nèi)存</b><b class='flag-5'>管理</b>的利器

    工業(yè)APP頻繁崩潰?聚徽廠家分享安卓工控機內(nèi)存碎片化與進程管理優(yōu)化指南

    與進程管理兩大核心維度,深入剖析崩潰根源,并提出系統(tǒng)性優(yōu)化方案。 一、內(nèi)存碎片化:工業(yè)APP崩潰的隱形推手 1. 內(nèi)存碎片化的成因與危害 內(nèi)存
    的頭像 發(fā)表于 06-10 10:24 ?545次閱讀

    HarmonyOS優(yōu)化應用內(nèi)存占用問題性能優(yōu)化四

    一、使用purgeable優(yōu)化C++內(nèi)存 Purgeable Memory是HarmonyOS中native層常用的內(nèi)存管理機制,可用于圖像處理的Bitmap、流媒體應用的一次性數(shù)據(jù)、圖片等
    發(fā)表于 05-24 17:20

    HarmonyOS優(yōu)化應用內(nèi)存占用問題性能優(yōu)化一

    一、 概述 用戶功能的不斷增強,應用越來越復雜,占用的內(nèi)存也在不斷膨脹,而內(nèi)存作為系統(tǒng)的稀缺資源比較有限,當應用程序占用過多內(nèi)存時,系統(tǒng)可能會頻繁進行內(nèi)存回收和重新分配,導致應用程序的
    發(fā)表于 05-21 11:27

    BMS管理方案NRF52833

    電池的智能化管理,同時提高電池使用壽命。通過 BMS 管理方案,結合手機APP、服務器數(shù)據(jù)統(tǒng)計分析,實現(xiàn)對電池系統(tǒng)的高效、安全和可靠管理,為
    發(fā)表于 04-22 14:26

    IEC61508系統(tǒng)中的動態(tài)內(nèi)存使用

    IEC 61508標準強烈推薦使用靜態(tài)內(nèi)存管理方式。在安全應用設計中,我們都在遵循這個建議。
    的頭像 發(fā)表于 04-11 15:17 ?1407次閱讀
    IEC61508系統(tǒng)中的動態(tài)<b class='flag-5'>內(nèi)存</b>使用

    BMS 管理方案 NRF52833

    電池的智能化管理,同時提高電池使用壽命。通過 BMS 管理方案,結合手機APP、服務器數(shù)據(jù)統(tǒng)計分析,實現(xiàn)對電池系統(tǒng)的高效、安全和可靠管理,為
    發(fā)表于 04-09 16:06

    快速搞懂C語言程序內(nèi)存分區(qū)!

    在程序運行過程中,操作系統(tǒng)會根據(jù)程序的需要,將內(nèi)存劃分為多個功能不同的區(qū)段,以便更高效地管理內(nèi)存資源和確保程序的穩(wěn)定運行。不同的內(nèi)存區(qū)段負責存儲不同類型的數(shù)據(jù)和代碼,涵蓋了從程序指令、
    的頭像 發(fā)表于 03-14 17:37 ?1591次閱讀
    快速搞懂C語言程序<b class='flag-5'>內(nèi)存</b>分區(qū)!