2024全國大學生計算機系統能力大賽全國總決賽-OS功能挑戰賽道答辯心得、教訓
雖然標題中寫的是"心得、教訓"，但因為本次比賽表現較差，主要還是記錄一下教訓。
場外因素的影響
因為平時比較喜歡熬夜，在去杭州的前一天晚上睡得很晚，當天又因為初到杭州十分亢奮，在旅途上全程沒有補覺。導致第二天白天（答辯前一天）非常困，幾乎整個白天的時間都呆在酒店裡睡覺。到了夜裡因為：
- 白天已經睡夠了
- 內心十分緊張
在雙重因素的作用下，整晚都沒有睡好覺，總睡眠時長只有兩個小時，導致第二天白天答辯前暈頭轉向、頭昏腦漲，嚴重影響了臨場發揮和隨機應變的能力。
因此，和社會普遍公認和接受的作息保持一致是非常有必要且有用的，可以很有效地減少這種情況的發生。
答辯現場
效能測試相關問題
雖然比賽前老師叮囑我們要對評委各種可能的提問方式做預案，但我們還是因為缺少相關經驗和麻痺大意，只著重準備了這兩類問題：
- 相比往屆作品有何優勢？
- 系統架構/設計思路
然而這些最後都沒能成為評委老師重點關注的問題。
在我們展示完畢之後，對我們的專案比較瞭解的評委老師都對效能測試方面的內容窮追猛打，但這恰好是我們最大的弱點：
- 負責測試的同學沒有來參加答辯
- 我們的測試環節做的非常粗糙
老師們提出的問題大概如下：
-
為什麼你們的malloc隨著分配規模的變化，效能變化會呈現出這樣的趨勢？
- 這個問題比較簡單，因為記憶體分配器的架構是我們自己設計的。
-
你們的作圖不規範，time連單位都沒有（我們直接沿用了往屆的測試指令碼，沒有自己進行編寫）
- 這個是前期的態度問題導致的。
-
比較瞭解的評委老師認為我們和memmalloc進行比較，是在挑軟柿子捏，認為我們不真實。
現場錯誤表現：因為被老師戳到痛點（我們確實不敢和比較高效的效能分配器作比較），所以只能支支吾吾地回答我們也和GNU的malloc進行了比較，而GNU的malloc是比較強的。但是可能老師對GNU這個名詞不是很熟悉，也可能因為我當時說話沒說清楚，老師對我的回答沒什麼反應。
正解：我們的技術文件裡，是有著我們的專案和其他相比memmalloc更優秀的往屆作品的比較結果的，我應該拿這些圖片來反駁評委老師；即使不拿出我們的技術文件裡的圖片，PPT裡的圖片起碼也有三條曲線，可以結合圖片告訴老師，這是我們和GNU的ptmalloc對比的結果，我們的效能是相近的。
當時一個非常大的錯誤就是怯場：評委老師不翻PPT，就不敢動，實際上，應該積極地挑對我們有利的內容進行展示。
至於負責測試的同學沒有到場這個問題，實際上也是有解決之道的：
- 測試工作很簡單，乾脆兩個人做完得了；
- 既然他不來，那麼他就有義務給出詳實的測試報告，包括測試的詳細內容和具體執行步驟，這樣我們可以以此為依據來回答老師們提出的問題。
回答老師提問的技巧
- 對專案比較瞭解的評委老師指出我們的效能測試資料過少之後：
現場錯誤表現：不敢正面回答問題，小聲劃拉我們的文件頁面。
正解：既然我們被老師質疑缺少測試，那麼這個時候，哪怕測試是不規範的，也要大膽地擺出來！畢竟我們的測試樣本已經被老師指出不規範了，這時候老師的問題已經轉移到"為什麼你們的測試這麼少"上面，這個時候大膽展示我們豐富的測試用例，可以挽回局面。
- 對專案不太瞭解的老師提問為什麼我們的page大小是4k：
現場錯誤表現：因為作業系統當中設定的是4k，保持一致
老師反駁：核心實現當中，可能大小和我們的4k是不一致的
出現錯誤的原因：老師問的page和我們所回答的page並不是一個東西，老師心裡帶著的概念是：作業系統底層實現中的page，而我此時腦袋裡想的卻是我們的基本單位page，事實上，我們的這個page只是我們針對malloc設計的一個記憶體管理單位而已，叫slot、span、arena什麼的都無所謂，應該首先向老師解釋清楚這兩個容易被混淆的概念，然後再進行進一步的解釋。
老師追問：為什麼要設定為4k呢？
組長回答：因為這一塊區域裡不僅要存放實際使用者分配的記憶體，還要記錄malloc的資訊，這二者受到不等式關係的約束，故選擇4k。
當時老師接受了這個解釋，但實際上這個並沒有答到點子上。
正解：
-
首先，如果一個單位過大，會導致內部碎片異常巨大，極大降低我們malloc的效率；
-
如果按照老師的這種思想，把它發展到極端，也就是把整塊記憶體當成一個單位，一次就直接把它分配出去了，這顯然是不合理的。
綜上，我們需要給每個層級設定一個合適的大小。 -
對專案不太瞭解的老師針對三模冗餘功能提出疑問，並且問道"如果發生了超過一位翻轉，那是不是就不行了？"：
現場錯誤表現：在解釋了糾錯功能之後，我針對老師的質疑，回答道：賽題只要求一個bit
正解：所謂"賽題只要求一個bit"這種發言，是回答這個問題最低階的形式；我應該在說明三模冗餘功能的基本原理之後，告訴老師：實際上糾錯任務本身，是能夠實現對無限bit的糾錯的，只要我們備份的夠多，或者遍歷的時候，用的時間複雜度越高，越接近O(n)，那理論上可以實現任意位的糾錯；但是我們賽題的前提是特種裝置、航空裝置，記憶體和CPU資源都十分緊張，我們必須平衡好糾錯的收益和代價；加之單粒子翻轉本身就是小機率事件，所以我們沒有必要考慮多位翻轉的情況，如果真的有那麼倒黴的話，估計航天器早就墜毀了；在回答這個問題之後，足以見得這位評委老師沒有認真聽我們的報告，因此，有必要再次強調，我們不僅有三模冗餘功能，還實現了奇偶校驗，他們一個是時間換空間，一個是空間換時間。
- 有比較瞭解的評委老師指出，雖然我們給存入實際地址的記憶體做了糾錯功能，但是本身的資訊位卻沒有做防糾錯。
我在看到hcmalloc的這個設計時，還認為是多次一舉。這位評委老師一語道破天機，這確實是我們在設計系統時一個非常可笑的疏漏了。
- 有評委老師問我們：你們是如何利用核心親密度機制來實現加速記憶體分配的？
現場錯誤回答：我在回答的時候舉了NUMA的例子，我說我們的目的是保證在記憶體都被繫結在同一個節點的同時，保證程序長期執行在同一個核心，減少切換次數，從而提高效能。
老師回話：NUMA不是什麼節點之類的（具體表述我忘了）而是CPU訪問不同記憶體的延遲天然不同，有差異。
災難性回答（實際上勉強及格）：我的回答是：哦，那這樣的話，我們的目的就是在保證"記憶體都被繫結在同一個節點的同時，保證程序長期執行在同一個核心，減少切換次數，從而提高效能。"
正解：當時我的腦子沒有轉過來，實際上我和老師已經在問題的基礎上達成共識了，那就是NUMA架構下CPU訪問不同記憶體的延遲不同，但是我和老師在"節點"的概念上理解存在偏差，我應該先指出，節點就是那些記憶體訪問速度不一樣的點，所以我們需要讓記憶體繫結在一個恆定的節點上，同時用Linux的taskset命令來綁核，這樣就能實現訪存延遲最小化。
其他問題
組長在展示時忘記提到我們的小記憶體分配有預分配功能，後來我在回答問題階段向老師補充說明了這一點，這屬於是不可控、不可預測事件了，教訓就是一定要儘可能地表述清楚，不要放過具有我們技術特色的細節實現。
總結
-
描述專案實現時不要太微觀，但是在宏觀層面要做到面面俱到，重點展現我們花了心思的地方。在一開始就描述全面、充分，防止在提問階段被評委老師抓住漏洞輸出。
-
不要怯場、不能慌。很多問題我在事後回顧時都能回答得很好，當時卻亂了陣腳答不上來，要注意鍛鍊心態，要自信大方！就像我們的前一組那名同學一樣，一個人也能舌戰群儒，並且達到非常優秀的水準（被拉去抽查專案實現）
-
要積極應戰，別犯拖延症。在開發階段，從初賽到最後的決賽，我們都是最後一段時間踩點完成的，這一點非常的不應該！正是時間上的緊張，導致我們的測試部分做的一塌糊塗；也正是因為時間緊張，我們沒能充分預見評委老師可能提出的各種***鑽問題，導致到提問環節表現差勁
-
面試和答辯，不要怕"把別人當傻子"，儘量詳細、清楚地說明，儘可能減少歧義和模糊的地方；在每一次表達時，一定要抓住一切機會，表明我們專案是有多麼困難（即使它實際上並沒有，但可能別人並沒有那麼瞭解這個領域），我們為了克服這個困難，費了多大力氣、用了多少巧思。