---
# System prepended metadata

title: 2025q1 Homework1 (ideas)

---

# 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 來驗證。