GitHub repo: https://github.com/firelzrd/bore-scheduler BORE 排程器著重在透過犧牲些許 fairness 來換取較低的 interactive task 的 scheduling latency。此外，其建構在 CFS 之上，並只對更新 vruntime 的程式碼做調整，整體改動相對其他非官方 CPU 排程器 (例如：CacULE, TT, Baby, Project C, MuQSS ^本文最下方提供相關超連結^) 可以說是相當小。 burst time 機制 BORE 在 sched_entity 結構體中加入一名為 burst_time 的成員，用於紀錄給定 schedule entity 總共的 CPU time (實際使用 CPU 的時間)，並輔助 burst score (用於取得 task 權重值的 index) 的計算，burst score 越高 (使用越多 CPU 時間)，代表 task 越不可能是 interactive task，因此 vruntime 增加的幅度就越大，以使得 interactive task 有較好的 scheduling latency 表現： @@ -885,6 +897,19 @@ static void update_curr(struct cfs_rq *cfs_rq) curr->sum_exec_runtime += delta_exec; schedstat_add(cfs_rq->exec_clock, delta_exec);

本工具用途為量化 scheduling latency / OS jitter。 量化方法 在各個處理器核上綁定 (pin) 一個執行緒，並以 clock_nanosleep() 進行 1 us 的 sleep。 在 sleep 結束後，呼叫 clock_gettime() 獲取當下 timestamp，並將其與原先指定的 wakeup 時間相減，所得的差即為 scheduling latency / OS jitter。 從上述介紹，我們可推斷 jitterdebugger 生成的 task 為 interactive task，因為其相關 task 大部分時候在 sleep。 使用方式

BPF (Berkeley Packet Filter) eBPF (extended BPF) is traditionally used to safely and securely accelerate the network path in Linux with custom logic specified by userspace. Notable changes from cBPF (classic BPF) to eBPF: 32-bit reg -> 64-bit reg 2 general purpose reg -> 10 general purpose reg + 1 frame pointer reg introduction of JIT compiler upgraded instruction set, but remains backward-compatibility to cBPF

contributed by < flawless0714 > 自我檢查清單 你是否詳閱 手機裡頭的 ARM 處理器：系列講座 呢？請紀錄學習過程中遇到的問題 請解釋 AArch64 個別通用暫存器的作用，依據 Linux on AArch64 ARM 64-bit Architecture 的描述，搭配實際的程式碼說明。提示: 簡報第 19 頁附有參考資訊 回答

測驗 δ -- 1 實作缺失位於函式 con_pop 中： node_t *node = queue->first; /* Node to be removed */ node_t *new_header = queue->first->next; /* become the first in the queue */ /* Queue is empty */ if (!new_header) { mtx_unlock(queue->first_mutex); return NULL;

Nginx (v1.18.0) 以下為處理單個 HTTP GET request 時發出的系統呼叫： 以 Intel Pin 動態觀察系統呼叫的使用： syscall #: 232 syscall #: 288 syscall #: 45 syscall #: 4 syscall #: 257

contributed by < foxhoundsk > 實驗環境 Ubuntu 20.04.1 LTS Kernel: 5.8.0-36-generic Memory: 32 GB Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian

COSCUP 2020 馮會鈞 Agenda What is XDP A load balancer based on XDP XDP playground What is XDP?

A playground for newbie to the XDP. Slide Environment Setup We use Clang as compiler for the eBPF, which requires at least v3.4.0 in order to build eBPF program. Note that GCC also has support for eBPF since version 10. First, create a virtual network environment for playing with the XDP safely:

contributed by < foxhoundsk > Benchmarking HAProxy: ./wrk -t8 -c250 -d60s -R20000 --latency http://10.10.0.2 Thread Stats Avg Stdev Max +/- Stdev Latency 1.08ms 480.11us 8.56ms 66.27% Req/Sec 2.64k 295.71 4.89k 71.14%

Homework HW1 - 10/16 unsigned int clz(unsigned int t) { unsigned int r = 0; if (!t) return 32; for (;; t <<= 1) { if (!(0x80000000 & t)) r++;

kprobe 與 kretprobe 之差別 kprobe 的註冊函式(register_kprobe()) 會將欲探測的函式的其中一條==指令==(instruction，在 amd64 架構下對應指令可能是 call)替換為 INT3 指令。 置放於被探測的 function 的進入點的的前後 參考資料 official document

contributed by < foxhoundsk > kernel version: 5.1.10 自我檢查清單 模組插入工具 insmod 是如何將初始化參數傳入核心模組 insmod 使用 finit_module(2) 進行將模組植入核心的動作，而這個系統呼叫的第二個參數(param_values)即是指向帶入參數的字串的指標。 finit_module 做完權限檢查以及將欲載入的模組預載(這邊使用預載一詞是因為之後會再 kmalloc 一塊實際使用的記憶體)到記憶體後會呼叫 load_module 以繼續進行模組載入。 load_module 在實際配置並載入(memcpy)模組需要的記憶體後，會呼叫一名為 find_module_sections 的函數，其作用是將模組的 ELF 檔中的各個 section 的位置找到並個別填入模組結構體(struct module)中對應的 field 內，這邊我們想關注的是結構體中名為 kp (struct kernel_param) 的 field，這個指標對應的 ELF section 是 __param。

contributed by < flawless0714 > 介紹 一般系統呼叫是以 synchronous 的方式完成，這種典型的實做方式在系統呼叫密集型(例如：網頁伺服器)的軟體中容易成為效能的瓶頸，主要原因有兩個： CPU 在進行 mode switch 時會 flush pipeline，此舉對 IPC (Instruction Per Cycle) 有直接的影響。 processor structure (registers, cache) 在系統呼叫過程中會被適度的 evict (每個 syscall 程度不一)，此舉則對 IPC 有間接的影響(cache miss, TLB miss)。 而 FlexSC 則是以 asynchronous 的方式來實做系統呼叫，並分別指定特定核心(kthread_bind(), sched_setaffinity())來處理系統呼叫，下圖為其執行之示意圖：

contributed by < flawless0714 > Kernel 版本: 4.15.0-47-generic 筆記 TCP backlog 原先擔心 kernel module 中的這項參數會影響測試，理解後得知其是在 accept() 成功前 queue 中最大能存放的連線要求，然而我的測試程式是在 accept() (以測試程式的角度看是 connect()) 成功後才會開始計時，所以這邊除非 queue 太容易塞滿，導致測試程式的部份執行緒沒有被涵蓋到 kecho 並行處理通訊時的情境。 kthread 工作於 kernel-space 的 thread。

# Tensorflow 建製教學 (on docker) ``` OS: Ubuntu 18.04 (docker is also availiable on Windows) arch: x86_64 ``` [實測](https://blog.exxactcorp.com/is-docker-ideal-for-running-tensorflow-lets-measure-performance-with-rtx-2080-ti/)證實 tensorflow 在實體機與 docker 中擁有幾乎相同的效能。 ## 環境建製 ### docker 移除舊版 docker: ```shell $ sudo apt-get remove docker docker-engine docker.io containerd runc ``` 更新 APT 的 package index: ```shell $ sudo apt-get update ``` 安裝透過 HTTPS 安裝套件需要的相關工具： ```shell $ sudo apt-get install \

# 2019q3 Homework1 (review) contributed by < `flawless0714` > ## 實驗環境 ``` OS: Ubuntu 18.04.3 LTS (kernel version: v5.0.0) GCC: 7.4.0 CPU arch: amd64 ``` 以下有關 Linux kernel 的程式碼其版本號均為 `v5.0.10`。 --- ## 題組 1 - [課程簡介和注意須知 Page 15](https://docs.google.com/presentation/d/1Wo22s5aYuuyry97-z2MMmUmdxhjD0wKTdhxIW5oqjvo/edit#slide=id.g613ce7d15f_1_15) ```cpp= #include <stdint.h> int32_t abs(int32_t x) { int32_t mask = (x >> 31); return (x + mask) ^ mask; } ``` ### 運作原理 上述程式碼第三行的 `mask` 拿到的是 `x`

# 2019q1 Homework2 (kcalc) contributed by: <`flawless0714`> ## 自我檢查清單 * 解釋浮點運算在 Linux 核心中為何需要特別對待，以及 context switch 的過程中，涉及到 FPU/SIMD context，該注意什麼？ * 提示: 參照 [Lazy FP state restore](https://en.wikipedia.org/wiki/Lazy_FP_state_restore) 和上方參考資料 * 應該撰寫對應包含浮點運算的 Linux 核心模組，實際編譯和測試 - **回答** - 因為浮點運算使用的暫存器較其他暫存器大，所以相對的進行浮點運算時假如發生 context switch 則會需要不小的時間開銷來保存 FPU state，而 kernel 幾乎每分每秒都在進行 context switch (system call, interrupts, switch between kernel threads)，假如每次 context switch

# 2019q1 Homework2 (fibdrv) contributed by < `flawless0714` > ## 執行環境 ``` OS: Lubuntu 18.04.1 LTS (Bionic Beaver) Kernel Version: 4.15.0-46-generic Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 142 Model name: Intel(R)

# 2019q1 Homework1 (list) contributed by < [flawless0714](https://github.com/flawless0714/linux-list) > Linux source code version: `4.20.13` ## 執行環境 ``` OS: Lubuntu 18.04.1 LTS (Bionic Beaver) Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: