版本 24b0b072fe0579c8e91ba4591137729acb3e7ee3
yenslife (潘駿諺)
簡介
2024 Linux 核心設計 春季班 自我評量
成果發表和貢獻
- lab0-c
- 《Demystifying the Linux CPU Scheduler》修訂
- Add explanations related to DEFINE_SCHED_CLASS (commit 670559f)
- Update sched_class.h for kernel v6.x (commit 5fd54f9)
- Update task_struct state docs for kernel v6.x (commit c22f920)
- Update task_struct.h for current Linux kernel (commit 1ff5d23)
- Improve section Per-Entity Load Tracking (commit 9bbbffe)
- Fix typos in scheduler.tex (commit be5a7cd)
評分: 10
「取之於網路,回饋於網路」,深受網路開源學習資料的影響,貢獻開源專案是我參與這堂課程的目標之一,雖然沒有對 Linux 核心做出貢獻,但我在閱讀老師撰寫的教材時,除了更新過時程式碼外,也提供相對應的解釋,以及我認為對讀者更好理解的詮釋方式。在第一次作業 lab0-c 撰寫開發紀錄的時候,老師在我的筆記問我「如何確保排序的『穩定性』」,“stable” 一詞我只在過去學習演算法課程的時候把定義背下來,但我從沒想過要怎麼確保一段排序程式碼是否為穩定排序。從一開始單純在每個排序元素的成員加上編號,到現在使用陣列來紀錄節點的位址,目前的實作還有進步空間,因為固定長度的陣列沒有辦法適用於任意大小的佇列,可以利用像是 sliding window、hlist 之類的技巧來避免使用固定數值的巨集。不斷和老師討論、修改電子書或是程式碼教材的過程也讓我知道原來把小事情做到好是很重要的,光是留意細節就可以贏過許多人。我認為我在課程教材方面做了不少貢獻,第一次貢獻開源專案的經歷讓深刻的體悟,因此給自己 10 分。
作業/隨堂測驗共筆
評分: 6
我沒有完整地完成每次作業,但是每次作業都有深刻學習及探討。lab0-c 讓我重新認識 C 語言,認知到自身能力不足,以為自己會 C 語言,遇到問題直接原形畢露,根本不算是有學過。提交 commit 的過程被老師提點說要好好撰寫 commit message,考慮到「人在做,Google 在看」所有的 commit message 都是使用英文撰寫,我的英文寫作沒有很好所以都是用 ChatGPT 幫我寫 commit message,這種工具導向去使用 AI 而不是把 AI 當成「神」的使用習慣對我來說很有幫助,不再需要害怕模型輸出的正確性,因為你請他幫忙的內容都是建立在你已知的知識之上,完成任務的效率才會更高。撰寫 commit message 的好習慣也導入至我的大三專題,和組員間的溝通有效率 (好的 commit message 可以節省大量溝通成本),因為我的作業和專題都是公開的,這個習慣也被我實習的主管稱讚 (從沒想過寫程式以外的事情能被稱讚)。以為自己會用 git 了但跟 C 語言一樣,只是以為自己懂了。除了 git rebase -i
, git cherry-pick
等實用的命令,在 Homework2 因為探討到 glibc 隨機函式的程式碼,老師教我用 git blame
, git log -S
等命令,藉由查看大型開源專案的 commit message 來學習前人實作的程式碼背後的想法,這讓我更重視工程上的溝通以及程式碼的 “Good taste”。不論是作業還是期末專題,我在修這堂課之前都以為自己會花很多時間撰寫程式碼和 debug,但事實是,很多時候我都在觀察別人寫的程式碼、撰寫文件和「思考」,我覺得思考是這堂課的核心,因為思考是需要花時間的,這件事在這個浮躁的時代很少人做得到,很少人會真的把課程教材 (像是原文書) 看完,大家都想要速成直接看到結果。但工程不是這樣運作的,動手做固然重要,但在動手之前的數學推導、統計還有規劃都更為重要。我沒有做完每次的作業,但扎實學習的體驗和成長讓我想給自己及格的 6 分。
期末專題
評分: 7
過去在學習作業系統排程相關章節時,課本 (恐龍書) 只有提到 round robin, FIFO, MLFQ 之類很單純的排序方法,老師的書《Demystifying the Linux CPU Scheduler》講的是現實世界的排程器,讓我很有興趣,因為期末專題的選擇也有電子書編撰 / 修訂的選項 (ch1, ch2),所以我選擇了這個專題,(當然還有練習英文這個原因)。和老師討論的時候,他說也知道現在的學生很少會把原文書從頭到尾看完,我也是一樣的,所以對我來說是一個挑戰,過程中也需要和目前的 Linux 程式碼去比較,觀察核心開發者的 commit message,並思考其背後修改的意義。我也是第一次看書還和作者討論、檢討書籍的錯誤,過往其實不太會去懷疑課程教材的內容,有什麼吃什麼,可能還消化不良,但是我的專題就是去改課程教材,也讓我在之後看到從網路上的文章,到這種專業的內容,都有自信帶著批評的心態去檢視。我給自己七分,因為雖然有達成目標 (一二章的修訂),但是我的閱讀、看程式碼的速度還不能帶我到後續的章節,所以給自己 7 分。
與授課教師的互動
- 一對一討論
- 05/03 16:30 確認任務、不要講風險、審視學習狀況、浮點數觀念釐清
- 06/29 16:00 確認電子書修訂情形、第二章內容釐清、定點數觀念釐清
- 課堂討論
- 3/21 課堂討論 針對穩定排序檢測的討論
- PR #177: Check if sorting implementation is stable
評分: 8
我跟老師約了兩次一對一討論,第一次 (05/03) 主要討論專題主題的選擇,那時候我說我會選擇電子書撰寫是因為做失敗的風險…一提到風險二字老師馬上提點我:「這麼說是很危險的,風險不是你該擔心的事,而是你的主管該擔心的事情,你要做的是去解決問題。」遇到任務總想挑簡單的做,在乎的風險也不過是成績對推甄的影響而已。不做困難的事情,那就跟其他人一樣,成績也只不過是一個過程,重要的是你能在課程結束後留下什麼?而不是只記得「資料結構 95 分」這種沒有什麼意義的「結果」。第一次的一對一討論老師也順便檢測我對浮點數的理解,談及為何他會這麼重視這樣的「小東西」,因為在一次研討會的會後,老師向一位大師請教了問題,但卻被大師用美式幽默的方式嘲諷到:「你知道什麼是浮點數嗎?」(因為小數點是浮動的,反向思考定點數的概念就知道) 讓我知道我只是以為自己理解了,但細節問到底還是不懂,那就是不懂,更遑論 Linux 核心。為什麼老師會一直強調數學的重要性,因為老師在一次代表公司參與通訊技術的制定研討會中,發現數小時的會議自己連插話的機會都沒有,因為人家談的是數學,是證明。其實我是有點震驚的,因為過去我會覺得像老師、教授這樣的「權威人士」(包含但不限於其他高學歷人士),都可以自然而然的有好的表現,就像我不會質疑一個博士生的數學能力,但我錯了,因為問題丟出來,面試的時候一翻兩瞪眼,不會就是不會,實力不足的事實不會因為你有碩士學歷就被忽略,因為我們要做的是面對真實世界的問題,不能再仗著自己是成大資工就以為自己多厲害。第二次約討論 (06/29) 的內容是針對電子書撰寫,我問老師為什麼不要把舊的程式碼留在書裡,不然之前改的就浪費了。老師就問我我的皮膚不也是每天都在更新嗎?很好笑但也是事實,這也是撰寫程式電子書的難點之一,因為世界一直在變動。
在 PR 底下確保排序穩定討論的過程也一直被老師說要 “refine your commit message”,一開始覺得有點煩,但如同剛才提到的,開源專案是會被全世界的人看到的,謹慎看待文件的撰寫是很重要的工程素養。我覺得我和老師的討論每次都有很大的收穫,所以給自己 8 分。
所見所聞所感
評分: 10
TODO: 自我評分及反思
自我評分
方案 B: 1 + floor(GEOMEAN)
(10 * 6 * 7 * 8 * 10) ^ (1/5) = 8.04021858
1 + floor(8.04021858) = 9
TODO: 完成上方自評後,採用方案 B 計算成績