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

{%hackmd NrmQUGbRQWemgwPfhzXj6g %}

# [Linux 核心專題: 並行化的 Redis 實作](https://hackmd.io/@sysprog/B1W2HKTER#Linux-%E6%A0%B8%E5%BF%83%E5%B0%88%E9%A1%8C-%E4%B8%A6%E8%A1%8C%E5%8C%96%E7%9A%84-Redis-%E5%AF%A6%E4%BD%9C)
## Userspace RCU 的 flavor
RCU 最常用在處理讀取多於寫入的情況，犧牲寫入的效能來最大化讀取操作。
RCU 一次只能有一個寫入者，這以 lock 保護。寫入的邏輯是先做出一個物件 (此時讀取端仍可自由讀舊物件)，然後更新 atomic 指標來指向新的物件。atomic 指標更新後，新的讀取端就會讀到新的物件。這讓寫入端完全不會擋到讀取端，適合讀取遠大於寫入的情況。

其中衍生的問題就是舊物件該如何釋放，若在讀取端仍在讀取舊物件時釋放會造成 segmatation fault ， 而更新完 atomic 指標後，到安全釋放舊物件的時間， 稱為 grace period。
要如何維持 grace period 的正確性，同時避免無止盡的等待，根據使用環境的不同， 會利用不同的 flavor 來解決問題。

[參考](https://hackmd.io/@sysprog/ry_6RHgS3#%E7%B0%A1%E8%BF%B0)

關於這方面我有個疑問:
1. 在文中下方的實驗結果顯示理論上應該表現最好的 QSBR 在實際測試中不如預期，然而，文中也提到 reader 要進行 1024 個讀取操作才進入 quiescent state ， 與 urcu 的 test_urcu_qsbr.c 相同。
然而，我在 [Linux 核心專題: RCU 研究](https://hackmd.io/@sysprog/ry_6RHgS3#RCU-%E5%90%84%E5%80%8B-flavor-%E7%9A%84%E6%87%89%E7%94%A8%E5%A0%B4%E6%99%AF) 中看到，若使用者清楚知道 reader 該如何定期的進入 quiescent state ， 才不會讓 writer 被 block 太久。
若能考慮實際應用場景，調整進入 quiescent state 需要的讀取操作(例如:
10 ~ 100 之間)並重新設計實驗，是否會有不同的結果？

## 執行緒數量對 mt-redis 的影響
文中提到執行序數量的增加，在超過某個數字之後，會因為 context switch 與 cache miss 的增加而導致效率下降，這讓我想到過去在調整 p_thread 的執行序數量時，也有同樣的現象。

文中也提到了解決辦法，藉由加入 CPU affinity，讓兩個執行緒執行在同一個 CPU ，使任務不要頻繁在不同 CPU 切換，以減少 context switch 與 cache miss 的增加速度，增加可擴展性。