欧美另类偷自拍视频二区,日本高清在线WWW3344

體系結(jié)構(gòu)相關(guān)

5.10版本中RISC-V架構(gòu)合入了UEFI這個(gè)大特性，這個(gè)特性由西數(shù)的兩位工程師AnupPatel和AtishPatra貢獻(xiàn)，共7個(gè)補(bǔ)丁，支持了earlyioremap，用于UEFI啟動(dòng)內(nèi)核所需的PE/COFFheader，theRISC-VEFIstub和EFIruntimeservices。

此外，5.10版本中有不少和ARM架構(gòu)相關(guān)的特性，例如之前提到的MTE補(bǔ)丁，該功能借助ARMv8架構(gòu)中不使用的幾個(gè)高地址bit位（參見(jiàn)ARMv8programmingguide描述的TBI：TopByteIgnore）作為tag，可以檢測(cè)下面錯(cuò)誤：boundsviolations,，use-after-free,use-after-return,use-out-of-scope，usebeforeinitialization。用戶空間MTE的支持和內(nèi)核MTE的selftest測(cè)試用例該版本都合入了。內(nèi)核空間MTE的支持則在5.11mergewindow合入。

這個(gè)版本還增強(qiáng)了pointerauthentication，Pointerauthentication可以降低ROP(Return-orientedprogramming）攻擊風(fēng)險(xiǎn)。和MTE類似，PAC使用了系統(tǒng)不使用的地址高位作為簽名（PAC），5.10的版本中，增強(qiáng)了PAC的生成算法，并且當(dāng)authenticate指令失敗，會(huì)產(chǎn)生fault。值得注意的是，如果fault發(fā)給用戶空間，這里的行為和之前的實(shí)現(xiàn)有變化，之前會(huì)給用戶空間發(fā)SIGSEGV（Invalidmemoryreference），而目前會(huì)發(fā)送SIGILL(IllegalInstruction)。另外一個(gè)需要注意的是，MTE和pointerauthentication都使用了地址都高位，如果同時(shí)打開(kāi)，PAC可用比特會(huì)減少。

Thearm64architecturecannowdoperformance-eventsmonitoringoverArm’sCMN-600interconnect

調(diào)測(cè)是系統(tǒng)軟件很重要的一部分能力，有純軟件的方式，也有軟硬結(jié)合的方式。例如想分析cache性能，可以通過(guò)硬件PMU（PerformanceMonitorUnit）得到cachemissrate等數(shù)據(jù)。PMU可以在CPU，總線等模塊中。這個(gè)補(bǔ)丁提到的PMU是系統(tǒng)總線中的PMU。

CMN-600是ARM公司與2016年推出的系統(tǒng)總線IP，最大支持128個(gè)處理器和8T內(nèi)存。CMN代表CoherentMeshNetwork，顧名思義，是個(gè)網(wǎng)絡(luò)結(jié)構(gòu)，它的基本結(jié)構(gòu)是XP（crosspoint）。CMN最大支持8x8=64個(gè)XP節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)可以支持兩個(gè)Device，例如處理器，IO設(shè)備等，也包括調(diào)測(cè)設(shè)備，例如DTC。DTC是DebugTraceController的縮寫，負(fù)責(zé)整體的PMU管理和中斷（XP節(jié)點(diǎn)中有l(wèi)ocalmonitor）。下圖來(lái)自CMN-600TRM，是一個(gè)3x5的mesh網(wǎng)絡(luò)例子。

Linux系統(tǒng)的PMU是事件（event），通常的做法是通過(guò)perf_pmu_register注冊(cè)。在armcmn實(shí)現(xiàn)中，arm_cmn_probe調(diào)用了該函數(shù)注冊(cè)pmu的attributegroup和pmu的event，也就是注冊(cè)該P(yáng)MU支持的調(diào)測(cè)能力。例如armcmn驅(qū)動(dòng)中注冊(cè)了400多種事件，其中PMU_HN_CACHE_MISS_EVENT和PMU_HNSLC_SF_CACHE_ACCESS_EVENT，可以用于計(jì)算cachemissrate（Cachemissrate(%)=Totalcachemisses/Totalcacheaccessesx100）。注冊(cè)后，調(diào)用者（例如perf_event_open）初始化并注冊(cè)event到perf_event_groups中，該event的相關(guān)處理函數(shù)是前述arm_cmn_probe注冊(cè)的。這是Linuxpmuevent通常的管理方式。cmn驅(qū)動(dòng)稍微多做了一些事情：cmn網(wǎng)絡(luò)需要通過(guò)discovery發(fā)現(xiàn)，而不是固定寫死的網(wǎng)絡(luò)；發(fā)現(xiàn)之后，需要初始化前述的DTC，并為DTC注冊(cè)中斷。

這個(gè)補(bǔ)丁分為兩部分，其中文檔簡(jiǎn)述了CMN-600以及PMU驅(qū)動(dòng)的一些實(shí)現(xiàn)考慮，具體實(shí)現(xiàn)在“drivers/perf/arm-cmn.c“，感興趣的童鞋可以根據(jù)前面內(nèi)容讀讀代碼（參見(jiàn)上圖，圖片節(jié)選自閱碼場(chǎng)張健老師的ARMLinux課程）。

文件系統(tǒng)和BlockLayer

ext4：兩個(gè)提升性能的改進(jìn)點(diǎn)

補(bǔ)丁1：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9faac62d40131521973192e46a82d5066bb42c09

補(bǔ)丁2：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5b8b297b04208e101c1f92fe804cd4e66df30e8

在ext4的iomap中，如果是復(fù)寫，在已經(jīng)映射了塊的情況下，直接使用已有的映射信息，而不是重新映射。一個(gè)非常簡(jiǎn)單的改動(dòng)，在DAX&DIO模式下，能大幅提升文件隨機(jī)復(fù)寫的速度。在使能了模擬pmem（DAX）的PPC64VM設(shè)備上測(cè)試，約有10倍的隨機(jī)復(fù)寫性能提升。但在常規(guī)的IO操作（非iomap）中，其實(shí)并不會(huì)有影響。

另外一個(gè)fastcommit的新功能實(shí)用性更強(qiáng)。在ext4的data=ordered的日志模式中，會(huì)在日志中記錄下完整的元數(shù)據(jù)。一個(gè)完整的元數(shù)據(jù)有時(shí)候也是有冗余的，大多時(shí)候改動(dòng)可能只有一點(diǎn)點(diǎn)。能不能只記錄涉及的最少改動(dòng)？這就是fastcommit新功能要做的事情。fast_commit的功能需要在mkfs時(shí)使能，已有的舊的ext4fs并不能生效。

overlayfs：新增volatile的掛載參數(shù)

補(bǔ)?。篽ttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c86243b090bc25f81abe33ddfa9fe833e02c4d64

我們通過(guò)sync來(lái)保證數(shù)據(jù)刷入，但如果太頻繁的sync卻會(huì)嚴(yán)重拖慢了性能。有使用者抱怨，dnf/yum安裝包時(shí)總會(huì)觸發(fā)大量的sync，嚴(yán)重拖慢了image的創(chuàng)建速度。

有些使用場(chǎng)景下，使用者并不希望頻繁響應(yīng)sync，只需要在umount時(shí)回刷overlayfs的upperlayer文件系統(tǒng)足夠了。甚至根本不在意upperlayer文件系統(tǒng)是否同步，如果數(shù)據(jù)不完整，丟棄并重新創(chuàng)建即可。

為了滿足這樣的需求，新支持了volatile掛載參數(shù)。在使能了這樣的掛載參數(shù)后，對(duì)upperlayer文件系統(tǒng)的任何形式的sync都會(huì)被忽略。

這個(gè)新的掛載參數(shù)并不常用，使用者應(yīng)根據(jù)自己的場(chǎng)景來(lái)確定是否使能。

null_blk：一個(gè)測(cè)試不同塊層實(shí)現(xiàn)的性能的模擬塊設(shè)備

補(bǔ)?。篽ttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dc4d137ee3b79a7474b747b4b326d472ccc2cb79

5.10合入了一個(gè)關(guān)于null_blk的優(yōu)化補(bǔ)丁，添加支持最大打開(kāi)和活躍的zones的限制。相信大多數(shù)人也是第一次聽(tīng)說(shuō)nullblock設(shè)備。/dev/null的字符設(shè)備用多了，nullblock是干嘛的呢？

nullblock的資料非常少，只因其使用場(chǎng)景也非常局限。在Linux的文檔中是少有的介紹nullblock設(shè)備的資料。nullblock模擬了一個(gè)塊設(shè)備，這個(gè)塊設(shè)備不響應(yīng)任何的讀寫操作，實(shí)際上，也僅僅是在request隊(duì)列中直接標(biāo)識(shí)request完成就返回了?？梢园l(fā)現(xiàn)，nullblock雖然不對(duì)應(yīng)任何具體的塊設(shè)備，但經(jīng)歷過(guò)完整的塊層，因此nullblock常用于測(cè)試不同塊層實(shí)現(xiàn)模型的性能，例如multi-queue塊層、single-queue塊層、bio-based。

虛擬化和容器

在5.10Release中我們?cè)谇皫讉€(gè)月介紹過(guò)的幾個(gè)補(bǔ)丁集已經(jīng)被合并：

1. AddsupportforNitroEnclaves。

NitroEnclaves(NE)是Amazon彈性計(jì)算云(EC2)的一種新功能。它允許客戶在EC2實(shí)例[1]內(nèi)部再分割出一塊隔離的計(jì)算環(huán)境。

例如，一個(gè)在虛擬機(jī)中運(yùn)行的用于處理敏感數(shù)據(jù)的應(yīng)用程序，可以和運(yùn)行在同一個(gè)虛擬機(jī)中的其它應(yīng)用程序分離開(kāi)。我們稱呼這個(gè)運(yùn)行EC2實(shí)例的虛擬機(jī)為主虛擬機(jī)。分離后，這個(gè)應(yīng)用程序運(yùn)行在和主虛擬機(jī)不同的另外一個(gè)單獨(dú)虛擬機(jī)里，也可以叫做enclave。

2. Supportvirtiocross-deviceresources。

這個(gè)補(bǔ)丁實(shí)現(xiàn)了VIRTIO跨設(shè)備的資源共享。他可以支持將VIRTIO資源導(dǎo)入到VIRTIO-VIDEO驅(qū)動(dòng)中。

3. virtiofs:AddsDAXsupport。

該特性允許客戶機(jī)在使用virtiofs文件系統(tǒng)時(shí)繞過(guò)客戶機(jī)的頁(yè)面緩存，同時(shí)允許客戶機(jī)將主機(jī)上的頁(yè)面緩存直接映射到客戶機(jī)地址空間。這在很多數(shù)情況下，都可以大大提高訪問(wèn)速度。因?yàn)槲募?shù)據(jù)不必在客戶機(jī)中復(fù)制，而是直接從主機(jī)頁(yè)面緩存中訪問(wèn)，這可以節(jié)省大量?jī)?nèi)存。

還有一些補(bǔ)丁集我們之前沒(méi)有介紹過(guò)，其中有一個(gè)關(guān)于vDPA的

vDPA:APIforreportingIOVArange：

這個(gè)補(bǔ)丁集導(dǎo)出了一個(gè)API，可以向用戶態(tài)程序報(bào)告IOVA范圍。這是這個(gè)API的功能，可以讓用戶太進(jìn)程根據(jù)返回的IOVA做出正確的決策:

1. 對(duì)于直接使用vhost-vDPA的用戶太進(jìn)程，IOVA必須在API返回的這個(gè)范圍內(nèi)分配。

2. 對(duì)于虛擬機(jī)(qemu)，當(dāng)vIOMMU未啟用時(shí)，如果GPA超出范圍，則在前期就會(huì)失敗。

3. 對(duì)于虛擬機(jī)(qemu)，當(dāng)vIOMMU被啟用時(shí)，確定一個(gè)有效的虛擬機(jī)地址的范圍大小

后，虛擬機(jī)的IOVA分配器就可以正常工作了。

這個(gè)補(bǔ)丁比較簡(jiǎn)單，但我們正好借此機(jī)會(huì)簡(jiǎn)單介紹下

vDPA（Virtualdatapathacceleration）：

vDPA本質(zhì)上是一種標(biāo)準(zhǔn)化的方法用來(lái)設(shè)計(jì)SRIOV的網(wǎng)卡。讓SRIOV網(wǎng)卡在數(shù)據(jù)面使用VIRTIORing的設(shè)計(jì)布局，這樣在虛擬機(jī)中就只需要單一的VIRTIO網(wǎng)卡驅(qū)動(dòng)，而不需要部屬各種廠商SRIOV網(wǎng)卡VF的驅(qū)動(dòng)。這樣相當(dāng)于將虛擬機(jī)和具體的網(wǎng)卡硬件廠商解耦。這不僅僅便于虛擬機(jī)的遷移，也方便于虛擬機(jī)鏡像的安全認(rèn)證，不再需要因?yàn)楦鼡Q了網(wǎng)卡的硬件添加了新的VF驅(qū)動(dòng)再去認(rèn)證虛擬機(jī)鏡像。除了數(shù)據(jù)面之外，它還定義了一個(gè)通用的控制面和軟件的底層基礎(chǔ)架構(gòu)來(lái)支持它。因此vDPA也可以被看作是SRIOV的一個(gè)上層抽象。

那么有的朋友可能會(huì)問(wèn)，這個(gè)和VIRTIOfulloffload到硬件的方案有什么區(qū)別？這個(gè)從虛擬機(jī)里面的最終使用者來(lái)看，其實(shí)沒(méi)有太大的區(qū)別，在虛擬機(jī)內(nèi)部都是使用一個(gè)VIRTIO網(wǎng)卡驅(qū)動(dòng)。vDPA帶來(lái)的是降低VIRTIO硬件網(wǎng)卡的設(shè)計(jì)難度，然后提供更好的設(shè)計(jì)靈活性。我們都知道一個(gè)VIRTIO設(shè)備包括數(shù)據(jù)面（通過(guò)vring中存儲(chǔ)數(shù)據(jù)）和控制面（vring的初始化等）。我們?cè)谏厦娴膙DPA中提到了控制面，但那個(gè)并不是VIRTIO控制面。

VIRTIOfulloffload方案中需要硬件廠商在網(wǎng)卡硬件層面實(shí)現(xiàn)VIRTIO的數(shù)據(jù)面和控制面，數(shù)據(jù)面的難度比較低，但是控制面會(huì)復(fù)雜很多，因?yàn)檫@個(gè)涉及和內(nèi)存管理單元（IOMMU）的交互。而且VIRTIOfulloffload也會(huì)帶來(lái)產(chǎn)品的同質(zhì)化，不利于廠商做差異化功能，這樣才有了vDPA。

vDPA的控制面可以簡(jiǎn)單看作是一個(gè)轉(zhuǎn)換層。虛擬機(jī)通過(guò)vDPA看到的仍然是VIRTIO的控制面接口，不是各個(gè)廠商定義的控制面接口。但是vDPA的控制面可以將虛擬機(jī)的VIRTIO控制命令，通過(guò)vDPA定義的通用控制面接口轉(zhuǎn)換為各個(gè)廠商自定義的接口。這只需要在主機(jī)端添加vDPA設(shè)備廠商提供的vDPAaddon驅(qū)動(dòng)即可。廠商的vDPA-addon驅(qū)動(dòng)可以包含它自己的接口和DMA訪問(wèn)模型支持等復(fù)雜功能。