薛子涵, 解 達(dá), 宋 威

1(中國科學(xué)院 信息工程研究所, 北京 100093)

2(中國科學(xué)院大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院, 北京 100049)

1 引言

現(xiàn)代處理器中一般都擁有若干被稱為硬件性能計(jì)數(shù)器(Hardware Performance Counter, HPC)的寄存器[1].這種寄存器只會(huì)按照軟件的配置在指定的事件發(fā)生時(shí)自增計(jì)數(shù), 對(duì)處理器的正常工作或者性能表現(xiàn)不會(huì)有影響.這些被記錄的信息能夠幫助軟件工程師對(duì)代碼進(jìn)行優(yōu)化, 也能夠協(xié)助計(jì)算機(jī)架構(gòu)師對(duì)處理器結(jié)構(gòu)進(jìn)行調(diào)優(yōu), 因此HPC幾乎成為所有現(xiàn)代處理器的標(biāo)配.作為近年來備受學(xué)術(shù)界和工業(yè)界關(guān)注的開源指令集RISC-V, 其處理器在設(shè)計(jì)之初就把HPC考慮了進(jìn)去并為其制定了相關(guān)標(biāo)準(zhǔn).RISC-V特權(quán)指令規(guī)范[2]定義了若干控制和狀態(tài)寄存器(Control and Status Registers,CSRs)作為計(jì)數(shù)器和選擇器.其中選擇器將一個(gè)或多個(gè)(微)體系結(jié)構(gòu)事件的信號(hào)接入計(jì)數(shù)器, 從而構(gòu)成了可捕獲特定事件的HPC.在現(xiàn)代處理器結(jié)構(gòu)愈發(fā)復(fù)雜的時(shí)代, 這種將HPC集中在CSR模塊內(nèi)的方式不利于HPC的拓展, 也限制了可同時(shí)監(jiān)測(cè)的體系結(jié)構(gòu)事件數(shù)量.為此, 本文設(shè)計(jì)了一種分布式的性能計(jì)數(shù)器.按照處理器內(nèi)部模塊的劃分, 將HPC分布在不同區(qū)域,并通過片上互連將HPC和CSR模塊連接, 從而降低了CSR模塊復(fù)雜度, 同時(shí)也為HPC的拓展提供了便利.

本文組織架構(gòu)如下: 第2節(jié)介紹了相關(guān)的背景知識(shí).第3節(jié)介紹了SiFive U74-MC[3]的性能計(jì)數(shù)器并分析其不足之處.第4節(jié)針對(duì)現(xiàn)有的HPC方案存在的問題, 提出了分布式的HPC方案.第5節(jié)完成了將分布式的HPC部署到lowRISC-v0.4[4], 通過運(yùn)行SPEC CPU2006[5]分析結(jié)果并評(píng)估該方案效果.第6節(jié)總結(jié)本文.

2 研究背景

2.1 RISC-V

RISC-V[6]是一種優(yōu)秀的開源指令集架構(gòu), 由加州大學(xué)伯克利分校于2010年發(fā)布.RISC-V充分吸取了其他指令集優(yōu)點(diǎn): 結(jié)構(gòu)優(yōu)雅便于實(shí)現(xiàn)、靈活性強(qiáng)方便拓展、免費(fèi)開源無須高昂的授權(quán)費(fèi)用、社區(qū)活躍工具鏈完善等[7,8].這些優(yōu)點(diǎn)使其得到了眾多科研團(tuán)隊(duì)和商業(yè)公司的青睞.目前已有平頭哥、SiFive在內(nèi)的商業(yè)公司推出了基于RISC-V指令集的處理器.然而RISC-V定義的HPC存在不足, 無法同時(shí)監(jiān)測(cè)多種體系結(jié)構(gòu)事件, 在使用中局限性較大.

2.2 RocketChip

RocketChip[9]是加州大學(xué)開源的基于RISC-V的64位處理器.其中RocketChip的Rocket處理器核采用5級(jí)標(biāo)量順序流水線, 采用Chisel (Constructing hardware in a Scala embedded language)語言開發(fā)[10].作為加州大學(xué)為推廣RISC-V而開發(fā)的開源處理器,RocketChip為全世界的科研團(tuán)隊(duì)提供了針對(duì)體系結(jié)構(gòu)研究的優(yōu)良平臺(tái).

2.3 lowRISC-v0.4

lowRISC-v0.4是劍橋大學(xué)開發(fā)的基于RocketChip的開源SoC, 其基本信息如表1所示[4].相比于其他開源SoC 項(xiàng)目lowRISC-v0.4加入的OSD (Open SoC Debug) 模塊[11]提供了函數(shù)追蹤、特權(quán)模式監(jiān)測(cè)、程序下載(通過UART接口)等功能.這些功能在代碼調(diào)試過程中提供了詳細(xì)的調(diào)試信息.本文利用OSD模塊與上位機(jī)結(jié)合的方式, 使得lowRISC-v0.4能夠自動(dòng)運(yùn)行SPEC CPU2006 benchmark[5], 并在運(yùn)行結(jié)束后讀取HPC, 獲取體系結(jié)構(gòu)事件的統(tǒng)計(jì)值, 從而驗(yàn)證HPC 能否正常工作.

表1 lowRISC-v0.4基本信息

2.4 硬件性能計(jì)數(shù)器

硬件性能計(jì)數(shù)器是一組能夠記錄(微)體系結(jié)構(gòu)事件發(fā)生次數(shù)的寄存器.這些事件通常包括時(shí)鐘周期數(shù)、已執(zhí)行指令數(shù)、分支預(yù)測(cè)失敗次數(shù)、各級(jí)緩存(cache)的缺失/命中次數(shù)、TLB (Translation Look-aside Buffer)的缺失/命中次數(shù)等[1].對(duì)于會(huì)造成流水線阻塞的事件,某些處理器中的HPC還會(huì)記錄該事件導(dǎo)致的阻塞周期數(shù)[13,14].這些寄存器通常作為系統(tǒng)寄存器(比如ARM中的System Register, RISC-V中的CSR), 從而能夠被指令直接訪問.盡管HPC不是處理器正常工作的必要組成單元, 也不會(huì)對(duì)處理器性能有影響, 然而HPC提供了硬件運(yùn)行過程中實(shí)時(shí)的狀態(tài)信息.利用這些信息我們能夠更加高效地對(duì)系統(tǒng)狀態(tài)進(jìn)行監(jiān)測(cè)[1]、對(duì)硬件資源進(jìn)行高效利用[15]、對(duì)功耗進(jìn)行合理管理[16]、對(duì)惡意代碼進(jìn)行有針對(duì)性的檢測(cè)[17,18]、對(duì)計(jì)算機(jī)系統(tǒng)結(jié)構(gòu)[19]進(jìn)行優(yōu)化.因此, 幾乎所有現(xiàn)代處理器都會(huì)配置該計(jì)數(shù)器.HPC的管理和配置工作通常由性能監(jiān)測(cè)單元(Performance Monitor Unit, PMU)完成.PMU為每一個(gè)HPC都分配了一個(gè)事件類型選擇寄存器, 當(dāng)(微)體系結(jié)構(gòu)中發(fā)生的事件和該寄存器選中的事件匹配時(shí), PMU就會(huì)控制對(duì)應(yīng)的HPC增加計(jì)數(shù)值.除了計(jì)數(shù)器和選擇寄存器這兩個(gè)成對(duì)出現(xiàn)的寄存器之外, 某些處理中的PMU還包含了其他寄存器, 從而可以提供更豐富、更強(qiáng)大的額外功能: 比如訪問控制、特權(quán)級(jí)過濾(如過濾用戶態(tài)下的事件)等.HPC的基本配置和訪問較為簡單, 通常只需在選擇寄存器中, 選中要監(jiān)控的事件.對(duì)于較為復(fù)雜的需要?jiǎng)t可以直接使用Linux下的開源工具—perf[20].經(jīng)過多年的發(fā)展, 商業(yè)處理器HPC的硬件結(jié)構(gòu)和軟件配套已經(jīng)十分完善, 能夠滿足各種應(yīng)用需求.然而, 迄今為止開源RISC-V處理器(如RocketChip, lowRISC)中的HPC存在功能簡陋、拓展性弱、能夠同時(shí)統(tǒng)計(jì)的體系結(jié)構(gòu)事件少等不足, 無法滿足對(duì)于體系結(jié)構(gòu)的研究需求.基于此本文設(shè)計(jì)、實(shí)現(xiàn)了一種分布式HPC,并使用該HPC進(jìn)行我們相關(guān)的體系結(jié)構(gòu)研究工作.

3 U74-MC的性能計(jì)數(shù)器

U74-MC[3]是由SiFive公司發(fā)布的基于RISC-V指令集的64位高性能多核處理器, 可應(yīng)用于數(shù)據(jù)中心、通信基站等對(duì)性能要求較高的場景.作為目前性能最優(yōu)的RISC-V處理器之一, U74-MC擁有功能全面的HPC.因此本文對(duì)U74-MC的HPC進(jìn)行了著重分析.U74-MC的HPC可以分為兩類: 第1類按照RISC-V特權(quán)指令規(guī)范, 將若干CSR作為HPC寄存器, 軟件可以通過CSR指令配置和訪問這些HPC.第2類專門用來統(tǒng)計(jì)L2的微體系結(jié)構(gòu)事件, 這類HPC不會(huì)占用CSR,而是像外設(shè)一樣通過MMIO (Memory-Mapped I/O,即內(nèi)存映射)與處理器核連接.為了便于區(qū)分, 本文把第1類稱為核內(nèi)HPC, 第2類稱為外設(shè)HPC.

3.1 核內(nèi)HPC

按照RISC-V特權(quán)指令規(guī)范[3], U74-MC分配了4個(gè)CSR作為HPC (這些計(jì)數(shù)器稱為mhpmcounter),其中兩個(gè)(mcycle和minstret)用于統(tǒng)計(jì)時(shí)鐘周期和已執(zhí)行指令數(shù), 其余兩個(gè)是可編程的CSR, 可用于夠捕獲選定的事件, 并完成計(jì)數(shù).事件的選擇由mphevent寄存器控制, 能夠選中某一種或某幾種事件.為了安全起見,用戶級(jí)(user-level)的程序不能配置該寄存器, 也無法直接訪問mhpmcounter, 只能在機(jī)器級(jí)(machine-level).程序在[m|s]counteren中開啟了對(duì)應(yīng)的計(jì)數(shù)器訪問權(quán)限后, 用戶級(jí)程序才被允許通過訪問hpmcounter, 從而間接獲取mhpmcounter中的存儲(chǔ)的計(jì)數(shù)值.即hpmcounter是mhpmcounter的影子寄存器(shadow CSR).

如圖1所示, 核內(nèi)HPC的寄存器位于CSR模塊內(nèi)部, 事件信號(hào)來自不同模塊.因此這種結(jié)構(gòu)的HPC擁有極低的訪問延時(shí), 軟件通過CSR命令能夠直接獲取HPC數(shù)據(jù).雖然核內(nèi)HPC結(jié)構(gòu)簡單, 便于實(shí)現(xiàn)且能夠滿足大部分應(yīng)用場景, 但仍存在不足: 首先, 無法同時(shí)監(jiān)測(cè)大量事件, 當(dāng)監(jiān)測(cè)事件大于核內(nèi)HPC數(shù)量時(shí),只能由軟件不斷切換監(jiān)測(cè)的事件類型.這種方式不僅損害了性能, 同時(shí)還降低了測(cè)量精度.其次, 計(jì)數(shù)器都集中在CSR區(qū)域, 而(微)體系結(jié)構(gòu)事件卻分布在如處理器核、緩存、直接存儲(chǔ)器訪問(Direct Memory Access,DMA)等各個(gè)模塊中.繁多的計(jì)數(shù)信號(hào)來源給前端設(shè)計(jì)和后端布線帶來了巨大挑戰(zhàn).

圖1 核內(nèi)HPC結(jié)構(gòu)

3.2 外設(shè)HPC

現(xiàn)代處理器內(nèi)部擁有種類眾多的模塊: 處理器核、緩存、DMA等, 將這些模塊的事件信息全部匯總在核內(nèi)HPC是很不明智的做法.將同一模塊的HPC集中在一起并作為外設(shè)連接到MMIO, 這樣就避免了核內(nèi)HPC計(jì)數(shù)信號(hào)過于分散的問題, 而且通過訪存指令(LOAD/STORE)就能對(duì)這些HPC進(jìn)行控制和訪問.U74-MC的L2 HPC就使用了這種設(shè)計(jì)方來案監(jiān)測(cè)L2緩存的(微)體系結(jié)構(gòu)事件.

如圖2所示, 外設(shè)HPC就像外設(shè)一樣通過MMIO連接至處理器核, 由于IO空間范圍較大, 此結(jié)構(gòu)具有較好的拓展性.外設(shè)HPC彌補(bǔ)了核內(nèi)HPC缺陷, 能夠同時(shí)監(jiān)測(cè)更多的(微)體系結(jié)構(gòu)事件.但仍有一些不足:首先, IO空間無法對(duì)用戶態(tài)下的程序直接可見, 訪問前需要經(jīng)過操作系統(tǒng)的映射, 從而產(chǎn)生不小的代價(jià).其次,MMIO由諸多外設(shè)共享, HPC數(shù)據(jù)可能被惡意外設(shè)獲取, 進(jìn)而被利用發(fā)起側(cè)信道攻擊, 引起難以監(jiān)測(cè)的安全問題.最后, 相比于CSR訪問命令, LOAD/STORE指令影響L1D (一級(jí)數(shù)據(jù)緩存)的缺失率, 即訪問HPC會(huì)影響測(cè)量的準(zhǔn)確性.

圖2 外設(shè)HPC結(jié)構(gòu)

4 分布式性能計(jì)數(shù)器

針對(duì)以上不足, 本文提出一種分布式的性能計(jì)數(shù)器方案, 該方案充分結(jié)合了核內(nèi)/外設(shè) HPC兩者優(yōu)點(diǎn):首先, 該結(jié)構(gòu)擁有眾多HPC, 能同時(shí)監(jiān)測(cè)上百種事件.其次, 易于使用, 利用3個(gè)CSR就夠控制和訪問這些HPC, 不影響L1D性能有更好的準(zhǔn)確性, 不占用MMIO,因此不會(huì)帶來地址映射的額外開銷.最后, 有著更好的安全特性, 能夠通過CSR的權(quán)限控制管理HPC的訪問, 從而避免了HPC被非法使用, 進(jìn)而導(dǎo)致側(cè)信道攻擊.

4.1 結(jié)構(gòu)

核內(nèi)HPC結(jié)構(gòu)模型中的每一個(gè)計(jì)數(shù)器都占據(jù)了1個(gè)CSR, 當(dāng)需要同時(shí)監(jiān)測(cè)更多事件時(shí), 就需要更多的CSR.如果將這些計(jì)數(shù)器從CSR中剝離出來, 根據(jù)其事件類型和觸發(fā)信號(hào)的來源, 將其分布在不同模塊中, 并通過片上互連, 將各個(gè)計(jì)數(shù)器和對(duì)應(yīng)的CSR相連, 這樣就可以通過使用少量的CSR來控制和訪問數(shù)量龐大的HPC, 按照這種策略, 本文設(shè)計(jì)了如圖3所示的分布式性能計(jì)數(shù)器.從圖3中可以清晰地看出它由3個(gè)重要部分組成: HPCManager, HPCClient和HPCInterconnect.而HPC的寄存器被分散在了HPCManager中.

圖3 分布式性能計(jì)數(shù)器結(jié)構(gòu)

HPCManager主要負(fù)責(zé)接收和處理來自HPCClient的數(shù)據(jù)請(qǐng)求, 根據(jù)請(qǐng)求命令去查找指定的HPC, 并把該HPC的數(shù)據(jù)返回給HPCClient.1個(gè)HPCManager最多可以容納64個(gè)HPC, 這些HPC并無編程功能, 每個(gè)計(jì)數(shù)器只能夠記錄特定的(微)體系結(jié)構(gòu)事件.HPC按照所屬模塊進(jìn)行劃分, 比如處理器核中的事件統(tǒng)一劃分給一個(gè)HPCManager, L2 (二級(jí)緩存)分片中的事件統(tǒng)一劃分給另一個(gè)HPCManager.當(dāng)模塊中的事件超過64種時(shí), 可為該模塊分配多個(gè)HPCManagerID.顯然, 相比于計(jì)數(shù)器集中在CSR中的方式, 這種按模塊去劃分的分布式方案拓展性更強(qiáng), 擁有更規(guī)整、更清晰的結(jié)構(gòu), 同時(shí)帶給后端布線的壓力也更小.

HPCClient主要負(fù)責(zé)向HPCManager發(fā)起HPC數(shù)據(jù)請(qǐng)求以及接收返回的數(shù)據(jù), 其結(jié)構(gòu)如圖4所示.可以看出, HPCClient位于處理器核中的CSR模塊, 它占用了3個(gè)CSR: hpcm (hardware performance counters bitmap),hpcc (hardware performance counters config)以及hpcr(hardware performance counters receive).通過這3個(gè)CSR, 軟件能夠獲取到任意HPC的數(shù)據(jù).它們的詳細(xì)內(nèi)容將在本文的4.2小節(jié)展開.

圖4 HPCClient結(jié)構(gòu)

HPCInterconnect則把HPCClient和HPCManager連接在一起, 并且把這兩種模塊的命令、數(shù)據(jù)傳遞到指定位置.HPCInterconnect采用循環(huán)優(yōu)先級(jí), 它保證了在多核結(jié)構(gòu)中, 每個(gè)核對(duì)HPCManager都擁有相同的優(yōu)先級(jí), 在多核同時(shí)向同一HPCManager發(fā)起請(qǐng)求時(shí),可以有效避免“餓死”的情況.

4.2 性能計(jì)數(shù)器占用的CSR

在CSR中定義了3個(gè)寄存器, 即hpcc, hpcm, hpcr,通過這3個(gè)寄存器來完成對(duì)HPC的管理和訪問.

hpcc 即 hardware performance counters config.其比特位分配情況如圖5所示.作為硬件性能計(jì)數(shù)器的功能配置寄存器, 該CSR功能包括: 向指定的HPCManager發(fā)起HPC請(qǐng)求、指示接收狀態(tài)、指示軟件讀取是否失敗等.

以下內(nèi)容是依據(jù)圖5對(duì)hpcc的功能劃分進(jìn)行說明:

圖5 hpcc寄存器

(1) trigger: hpcc[0] ReadWrite

該位主要功能是發(fā)起和取消HPC請(qǐng)求.如果此位為0, 則表示當(dāng)前沒有正在進(jìn)行的HPC請(qǐng)求, 這時(shí)寫入1就可以觸發(fā)一次新的HPC請(qǐng)求.若此位為1, 則表示有正在進(jìn)行的HPC請(qǐng)求, 軟件可以通過寫入0的方式來撤銷當(dāng)前未完成的請(qǐng)求.當(dāng)HPCClient接收完所有指定的數(shù)據(jù)后, trigger會(huì)自動(dòng)復(fù)位, 表示完成了1次請(qǐng)求, 即所有需要的HPC數(shù)據(jù)均已存入fifo.

(2) interrupted: hpcc[1] ReadOnly

該位用于表示HPC在請(qǐng)求過程中, 是否發(fā)生過上下文切換.當(dāng)軟件寫hpcm時(shí), 該位自動(dòng)復(fù)位, 當(dāng)上下文切換時(shí), interrupted自動(dòng)置位, 表示HPC請(qǐng)求階段可能出現(xiàn)數(shù)據(jù)錯(cuò)誤, 需要重新發(fā)起請(qǐng)求.軟件只擁有該位的讀取權(quán)限.

(3) empty: hpcc[2] ReadOnly

該位用于表示接收返回?cái)?shù)據(jù)的fifo狀態(tài).當(dāng)fifo空時(shí), 該位會(huì)被置位, 否則被復(fù)位.當(dāng)軟件寫hpcm時(shí)該位自動(dòng)置位, 軟件只擁有該位的讀取權(quán)限.利用empty, 我們可以實(shí)現(xiàn)更快速地HPC讀取, 當(dāng)empty復(fù)位后, 軟件就可以開始讀取該數(shù)值, 而不必等到接收完HPCManager返回的所有數(shù)據(jù)(此時(shí)trigger自動(dòng)復(fù)位)才開始讀取工作.因而把該位當(dāng)作讀取開始的判斷依據(jù), 能夠節(jié)約一定的時(shí)鐘周期.

(4) readerror: hpcc[3] ReadOnly

該位用于表示軟件讀取HPC時(shí)是否發(fā)生了錯(cuò)誤.當(dāng)軟件寫hpcm時(shí), 該位自動(dòng)復(fù)位, 當(dāng)軟件從空的fifo中讀出了數(shù)據(jù)時(shí), 該位置位, 表示讀到了錯(cuò)誤的數(shù)據(jù).軟件只擁有該位的讀取權(quán)限.

(5) HPCMangerID: hpcc[20:4] ReadWrite

即HPCManager的ID.軟件向該位寫入正確的ID號(hào), 從而在選中預(yù)期的HPCManager之后, 置位trigger就能向該HPCManager發(fā)起HPC請(qǐng)求.為了增強(qiáng)擴(kuò)展性, 該位無法獨(dú)立工作, 需要與hpcm寄存器配合使用.事實(shí)上, HPC可以按照任意規(guī)則劃分到HPCManager,本著“一種邏輯清晰的劃分規(guī)則, 既能給使用者帶來便利也能夠減輕后端布線的壓力”的思想, 本文采取按照“模塊化”的劃分策略, 將HPCMangerID分割成module和extend兩部分, module指的是處理器核0, 處理器核1, 末級(jí)緩存分片0, 末級(jí)緩存分片1等模塊.而復(fù)雜模塊內(nèi)的事件數(shù)量通常會(huì)超過64, 因此會(huì)使用extend對(duì)模塊分配多個(gè)HPCManagerID.

useren: hpcc[21] ReadWrite

該位用于對(duì)用戶級(jí)程序HPC訪問權(quán)限的控制, 用戶級(jí)的程序?qū)υ撐恢挥凶x取的權(quán)限, 只有機(jī)器級(jí)或特權(quán)級(jí)下的程序能夠?qū)υ撐贿M(jìn)行更改.若此位為1, 則用戶級(jí)的程序能夠發(fā)起HPC請(qǐng)求, 否則用戶級(jí)的程序在置位trigger時(shí)會(huì)觸發(fā)異常.該位的置位復(fù)位可以由操作系統(tǒng)完成, 這樣能夠?qū)θ我膺M(jìn)程進(jìn)行HPC訪問權(quán)限的控制.避免了HPC數(shù)據(jù)被惡意程序利用, 有著很好的安全特性.

hpcm即 hardware performance counters bitmap.作為硬件性能計(jì)數(shù)器的位圖選擇器, 該寄存器的每一比特都對(duì)應(yīng)HPCManager中的1個(gè)HPC.當(dāng)hpcc.trigger處于復(fù)位狀態(tài)時(shí), 軟件擁有hpcm的寫權(quán)限, 否則軟件只能讀取該寄存器.當(dāng) HPCClient按照HPCMangerID指示向目標(biāo)HPCManager發(fā)起請(qǐng)求時(shí), hpcm選定了要讀取的HPC, 同時(shí)該寄存器自動(dòng)復(fù)位.之后每接收到HPCManager返回的1個(gè)HPC, 就將對(duì)應(yīng)的比特位置位, 通過讀取該位, 軟件可以知曉已接收到的HPC.受限于寄存器最大位寬, 因此每次選取的HPC不能超過64個(gè), 從而理論上, 1個(gè)HPCManager最多管理64個(gè)計(jì)數(shù)器.為不同模塊分配單獨(dú)的HPCManager, 記錄了不同模塊內(nèi)部的(微)體系結(jié)構(gòu)事件, 目前支持的事件和對(duì)應(yīng)的hpcm位圖如表2所示.read表示讀取緩存的次數(shù).readmiss表示讀取緩存, 但發(fā)生數(shù)據(jù)缺失的次數(shù).write表示向緩存寫入數(shù)據(jù)的次數(shù).writemiss表示向緩存寫入數(shù)據(jù), 但是發(fā)生缺失的次數(shù).writeback表示將緩存中的數(shù)據(jù)寫入下一級(jí)緩存或者內(nèi)存中的次數(shù).

表2 記錄的事件和其所在位置

hpcr作為硬件性能計(jì)數(shù)器的接收寄存器, 軟件只有該寄存器的讀取權(quán)限.通過讀取該寄存器, 軟件可以獲得HPC數(shù)值.hpcr是直接連接到fifo輸出端口, 軟件每讀取一次hpcr, fifo就會(huì)彈出一個(gè)新的數(shù)據(jù)存入hpcr寄存器.當(dāng)fifo為空時(shí)就會(huì)把過時(shí)或錯(cuò)誤的數(shù)據(jù)存入該寄存器.發(fā)起HPC請(qǐng)求后, 軟件可以在hpcc.trigger由1變0后才開始讀取hpcr (表示當(dāng)前的HPC全部接收完畢), 也可以在hpcc.empty由1變0后立刻讀取(表示當(dāng)前接收到有返回的HPC).在沒有異?；蚶獾那闆r下, 兩者得到的數(shù)值以及數(shù)值順序完全相同, 且后者更節(jié)約時(shí)鐘周期, 尤其在請(qǐng)求的HPC數(shù)量較多的情況中.

4.3 編程模型

在裸機(jī)環(huán)境(bare metal environment)中, 不存在多個(gè)線程對(duì)HPC控制權(quán)的爭搶問題, 配置并訪問HPC十分簡單.算法1適用于裸機(jī)環(huán)境下獲取HPC數(shù)值:行①使用CSR置位指令, 將bitmap寫入hpcm寄存器,其中bitmap代表選中HPCManager中的某幾個(gè)HPC.行② id用來選中HPCManager, 置位trigger會(huì)觸發(fā)對(duì)HPCManager的請(qǐng)求.行④等待HPCManager返回?cái)?shù)據(jù)(empty復(fù)位).行⑤empty復(fù)位后, 軟件讀取hpcr并將得到的HPC數(shù)據(jù)存入數(shù)組.

算法1.裸機(jī)環(huán)境HPC的訪問輸入: HPCM 的id和HPC對(duì)應(yīng)的bitmap輸出: HPC記錄的數(shù)據(jù)Function get_HPCs(id, bitmap):① set_csr(hpcm, bitmap);② set_csr(hpcc, id&trigger);③ for(i=0; i＜=hpcnumber; i++) {④ while(get_csr(hpcc.empty));⑤ hpcs[i]=get_csr(hpcr);⑥ }

在多線程環(huán)境下, 可能會(huì)出現(xiàn)同一個(gè)處理器核中的多個(gè)線程同時(shí)向HPC發(fā)起請(qǐng)求.HPC的獲取需要HPC的3個(gè)寄存器相互配合, 當(dāng)配置工作被其他線程打斷, 則會(huì)出現(xiàn)意想不到的錯(cuò)誤.針對(duì)這種問題, 我們通過使用“軟件鎖”, 防止多個(gè)程序同時(shí)對(duì)HPC的3個(gè)寄存器進(jìn)行控制和訪問.然而“軟件鎖”不僅實(shí)現(xiàn)復(fù)雜而且開銷較大, 對(duì)測(cè)量精度有影響.為此, 我們通過監(jiān)測(cè)hpcc.interrupted位, 來判斷HPC的請(qǐng)求程序是否發(fā)生過中斷.當(dāng)系統(tǒng)中線程個(gè)數(shù)與中斷次數(shù)均較少時(shí), 這種方式的失敗率可以忽略.這種方法編程簡單、易于實(shí)現(xiàn), 不會(huì)給系統(tǒng)帶來過多的額外開銷, 更加適合我們的研究工作.其具體算法如算法2所示: 行②復(fù)位hpcc寄存器, 終止可能正在進(jìn)行的HPC請(qǐng)求.行③至行⑧如算法1, 獲取HPC數(shù)據(jù)并存入數(shù)組.行⑨判斷上述操作是否出現(xiàn)上下文切換, 若出現(xiàn)過上下文切換, 則返回到行②處.

算法2.多線程中HPC的訪問輸入: HPCM 的id和HPC對(duì)應(yīng)的bitmap輸出: HPC記錄的數(shù)據(jù)Function get_HPCs(id, bitmap):① do {② clear_csr(hpcc.trigger);③ set_csr(hpcm, bitmap);④ set_csr(hpcc, id&trigger);⑤ for(i=0; i＜=hpcnumber; i++) {⑥ while(get_csr(hpcc.empty));⑦ hpcs[i]=get_csr(hpcr);⑧ }⑨ } while(get_csr(hpcc.interruped))

5 結(jié)果與分析

我們通過將本文設(shè)計(jì)的分布式硬件性能計(jì)數(shù)器,部署在lowRISC-v0.4上, 其消耗的資源如表3所示.可以看出本文的設(shè)計(jì)硬件開銷較小: LUTs和Registers分別占用了1.66%和6.29%.其中, HPCClient使用寄存器相對(duì)較多, 其原因是用于接收HPC數(shù)據(jù)的緩沖區(qū)容量較大.lowRISC-v0.4能夠以50 MHz的頻率工作在Genesys2開發(fā)板[12], 其工作頻率并沒有受到HPC的影響.通過使用OSD模塊, 我們實(shí)現(xiàn)了lowRISC-v0.4可以自動(dòng)運(yùn)行SPEC CPU2006的各個(gè)整數(shù)測(cè)試集,在運(yùn)行完一百億條指令后, 采用算法1讀取HPC.每個(gè)基準(zhǔn)的測(cè)試用例結(jié)果的平均值如表4所示, 可以看出L2的讀取次數(shù)等于指令緩存和數(shù)據(jù)緩存的缺失次數(shù)之和, 符合L1和L2包含關(guān)系.結(jié)合表3、表4, 我們可以得出一個(gè)結(jié)論: 分布式的HPC能夠以極少的硬件資源為代價(jià), 實(shí)現(xiàn)了準(zhǔn)確地記錄時(shí)鐘周期、執(zhí)行指令數(shù)以及L1與L2各分片的讀寫次數(shù)和缺失次數(shù).

表3 性能計(jì)數(shù)器資源消耗情況

表4 SPEC CPU2006 (整數(shù))運(yùn)行結(jié)果

6 結(jié)論與展望

表5將分布式的HPC和SiFive公司的U74-MC處理器所包含的兩類HPC進(jìn)行對(duì)比: U74-MC的核內(nèi)型HPC結(jié)構(gòu)簡單安全性強(qiáng), 但是在監(jiān)測(cè)大量事件時(shí),需要依靠軟件不斷切換監(jiān)測(cè)事件, 既增加了編程代碼也降低了測(cè)量精度.U74-MC的外設(shè)型HPC將計(jì)數(shù)器部署在IO空間, 因此有很大的拓展空間, 能夠同時(shí)監(jiān)測(cè)大量事件, 然而由于通過MMIO連接, HPC數(shù)據(jù)可能泄露給惡意外設(shè), 對(duì)處理器安全有一定影響.而且外設(shè)型HPC需要LOAD/STORE指令訪問, 這些指令對(duì)L1D的缺失率有一定影響.本文設(shè)計(jì)的分布式HPC為每個(gè)事件都單獨(dú)分配了計(jì)數(shù)器, 因而測(cè)量精度得到了保障.根據(jù)事件種類將計(jì)數(shù)器部署在不同HPCManager中, 并利用獨(dú)立的HPC互連將這HPCManager和處理器核中的HPCClient進(jìn)行連接, 因此分布式HPC有著很大的拓展空間和很好的安全性.除此之外該方案僅使用3個(gè)CSR就能訪問所有的HPC, 避免了對(duì)CSR資源的過多占用.這些優(yōu)點(diǎn)給我們之后的相關(guān)研究工作帶來了極大的便利.但仍存在諸多缺陷: 首先分布式的HPC只適用于64位處理器, 通用性較差.其次精力所限, 本文提出的方案沒有經(jīng)過嚴(yán)格測(cè)試無法保障穩(wěn)定性, 只適合研究工作.再次相較于商業(yè)處理器提供的眾多監(jiān)測(cè)事件, 本方案目前監(jiān)測(cè)的事件種類少, 只統(tǒng)計(jì)了我們研究需要的事件.這些不足均需要后續(xù)完善.

表5 3種HPC特點(diǎn)對(duì)比