1 INTRODUCTION
GPU需要大的kernel吞吐量來體現GPU的運算優勢，但是以前的研究都是針對單個kernel的運行優化，但是單個kernel一般都無法充分利用GPU的資源。而現在的GPU調度都是一個kernel佔據GPU然後運行完之後再進行下一個kernel的執行。因此論文提出了一些優化策略，主要思想就是kernel slicing。也就是將大的kernel通過分成較少的block的方式，讓多個kernel能夠並行執行，以提高GPU的利用率。
所要解決的問題就是分片的粒度和如何調度分片使得GPU的利用率最大。
提出的名爲"kernelet"的方法，能夠動態的分片和調度，使用馬爾科夫鏈指導kernel分片和調度策略，通過貪心算法來運行分片後的kernel執行，解決了上述問題，提高了GPU的吞吐量。
2 BACKGROUND AND PROBLEM DEFINITION
2.1 GPU Architectures
主要是介紹GPU的一些內容，這裏着重注意的是，並沒有強調reg和smem對於occupancy的影響，而是假設kernel的reg和smem都不會超過限度
2.2 Problem Definition
Application Scenario
提出本文的應用場景，一個是GPU Server內多個虛擬的用戶對於GPU的訪問，一個是Server外多個終端對於GPU的訪問，本文所提出的方法對這兩種場景都適用。
之後提出文章的兩點假設
- 本文的kernel運行在單個GPU上，能夠被靈活調度，且不規定kernel到來的順序
- 每個kernel的block相互獨立。
然後介紹了一些文章中的基本概念，以及要解決的問題就是在給定的一系列kernel組合中，如何執行分片和調度，使得總運行時間最少。
3 SYSTEM OVERVIEW
3.1 Design Rationale
由於是解決一組kernel的調度問題，所以需要考慮新來的kernel的調度；同時，分片和調度系統需要很小的開銷。
爲了實現上述目標，提出了三點：
- 兩層調度器，一個memory和一個kernel調度器。memory調度器重點在於充分利用PCI-e的帶寬，kernel調度器在於充分利用GPU的資源。
- 只考慮兩個kernel的調度，因爲已有的研究證明多個kernel的調度優化是NP完全問題。
- 兩個kernel的分片大小一旦固定就不改變
3.2 System Overview
分爲等待隊列和就緒隊列，到來的kernel如果數據還在傳輸，就放在等待隊列，一旦數據傳輸完成，就進入就緒隊列。針對已經就緒的kernel，根據性能模型來調度兩個kernel。
4 KERNELET METHODOLOGY
4.1 Kernel Slicing
首先設置了分片的開銷閾值，所需分片造成的程序開銷需要低於這個閾值。分片的原理就是在假設block獨立的情況下，在每次啓動kernel的時候提供一個修正過的index，使得多次啓動kernel所得到的block index和未分片一樣。
4.2 Scheduling
調度算法如下：
1. 定義R爲一組等待執行的kernel
2. if 新來的kernel K加入
3. 將K加入R中
4. 對K進行性能檢測
5. while R!=NULL do
6. <K1,K2,size1,size2> = FindCoSchedule(R)
7. 將得到的輸出定爲策略c
8. 執行策略c
9. while R 不變，並且K1和K2都還有block
10. 繼續執行c
函數FindCoSchedule(R)
1. 生成c的備選空間
2. 執行剪枝
3. 應用模型計算所有的CP
4. 得到最大的CP組合策略c
5. 返回c
4.3 Performance Model
就是使用馬爾科夫鏈模型來得到集合中最優的kernel和分片組合。
這裏要注意的是Heterogeneous Workloads一節中寫到，通過讓兩個kernel的執行時間差距最小，才能夠最大限度增加kernel的並行度，也就是說，實際上兩個kernel並行的情況下，模型所追求的是兩個kernel執行時間差最小，來減少下兩個kernel等待的時間，也就是說其他等待執行的kernel要等待這兩個kernel完全執行完纔可以進行下一步調度。算法實際上描述很有問題。
剩餘
下面都是實驗之類的，就不寫了
總結
實際上這個論文有一個關鍵問題，就是論文中說分片的開銷在GTX680上十分小(< 3%)，但是我在實際實驗中發現開銷很大(> 10%)，並且在一篇2017ASPLOS文章中，也有實驗證明實際上分片的開銷很大。我很迷惑文章中的實驗到底是怎麼做出來的，並且文章的算法很有誤導性，如果只看算法的描述，是能夠解決兩個kernel並行時，其中一個kernel完成，另外一個kernel未完成時的問題，實際上如果真正按照這個算法來執行，必定會產生很多程序“碎渣”，這在實驗中也沒有體現，任務的實時性根本沒辦法保證，只是增加整體的吞吐量這看起來毫無意義