# 2025q1 Homework1 (ideas)
contributed by < `chensheep` >

{%hackmd NrmQUGbRQWemgwPfhzXj6g %}

## 運用並行處理來強化網站資料存取的效率 : yeh-sudo

- 本質上還是一個 single threaded 的資料庫，大量並行處理的情況下會有效能瓶頸。
- Redis 2024 年修改授權條款，ValKey 是從舊版本 Redis fork 出來的專案。
- 開發環境
- Linux andyyeh-ubuntu 6.5.0-21-generic
- gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
- AMD Ryzen 7 4800HS
- RCU：一種同步機制，允許多個 reader 讀取資料，同時一個 writer 更新資料

- Linux kernel 的各種鎖，透過鎖的機制保護 critical section 就會有效能損失，所以後來出現 lock-free programming 跟 RCU
- Spinlock 與 Semaphore 一次只能讓一個執行緒進入 critical section，有可能造成效能瓶頸
- Ticket Spinlock：每個執行緒獲取各自的 ticket 判斷能不能進入 critical section，缺點是必須更新每個 CPU 裡面的 ticket，更新方式是透過廣播，會損失非常多的效能
- MCS Spinlock：解決 Ticket Spinlock cache coherence 的問題，但本質上還是只能讓一個執行緒進入 critical section
- Read-Write Lock：允與多個 reader 同時讀取資料，當有 reader 讀取資料時 writer 不可以進行更新，需等到所有 reader 都退出 critical section

- User-space RCU
- 類似 Linux kernel 的 RCU 但實做在 user-space
- 5 種 flavor 目的是支援不同的作業系統和版本

- URCU Flavors
- RCU using sys_membarrier() system call (liburcu) 預設
- Memory-barrier-based RCU (liburcu-mb) 與上面那種的差別在於沒有使用系統呼叫
- Signal-based RCU (linurcu-signal) 透過 writer 向 reader 發送訊號來同步
- Bullet-proof RCU (liburcu-bp) 使用上最簡單，效能最差
- QSBR (liburcu-qsbr) 最特別，需手動讓執行緒進出 quiescent-state (待確認)，執行緒不處理 critical section 時就處於這個狀態，官方範例是每 1024 個讀取就退出，讓一個 writer 進去更新資料，效能理論上最好，reader 端幾乎沒有成本。

- 測試方式透過 memtier_benchmark 有三個場景，
- Cache 10:1
- Cache 100:1
- Session store 1:1

20:14

## 建構 RISC-V 相容處理器並運作 Linux 核心 : millaker

- 要如何驗證我們開發的 RISC-V 處理器能運作呢？利用 Linux 來驗證。