Tổng kết module — Đường đi I/O & GPU

TL;DR: Module này lần theo một tuyến đường duy nhất, từ chỗ CPU chạm vào thanh ghi thiết bị cho tới chỗ dữ liệu nằm trong biến của chương trình bạn. Trên tuyến ấy có bốn câu hỏi lặp đi lặp lại ở mọi tầng: ai chủ động, ai tốn chu kỳ CPU, dữ liệu bị chép mấy lần, và cái gì đang chờ cái gì. Trả lời được bốn câu đó ở một tầng bất kỳ thì bạn chẩn đoán được tầng ấy. Đây là một trang để đánh dấu và quay lại.

Đã đi qua những gì

Bạn bắt đầu ở chỗ thấp nhất mà phần mềm còn với tới: vài thanh ghi nằm trong không gian địa chỉ vật lý, và một cái cây PCIe nối chúng về CPU. Từ đó lên một nấc, câu hỏi đổi thành ai trả tiền cho việc chờ và việc chép, và câu trả lời hoá ra không cố định — polling thắng interrupt ở tốc độ cao, đúng chỗ trực giác nói ngược lại.

Bài 03 ráp mọi thứ thành một tuyến đường liền mạch, và từ đó hai bài kế tiếp tấn công hai trục tối ưu khác nhau: cách chờ, và số bản sao. Hai bài cuối lấy GPU làm ví dụ cực đoan — một cỗ máy tính toán mạnh tới mức chính đoạn dây nối nó với CPU trở thành nút thắt.

🗺️ Cheat sheet

📖 Glossary module

⚠️ Pitfall tổng hợp

❌ Coi thanh ghi thiết bị như biến thường → ✅ Dùng readl/writel với con trỏ __iomem; con trỏ trần thì trình biên dịch bỏ mất lần đọc thứ hai và vòng lặp chờ quay vô tận.

❌ Tin rằng ghi ra PCI xong là thiết bị đã nhận → ✅ Ghi là posted; đọc ngược lại một thanh ghi của chính thiết bị đó mới có bảo đảm.

❌ Coi polling luôn là lãng phí → ✅ Ở tần suất cao, interrupt gây livelock; NAPI cố ý chuyển sang polling, và driver độ trễ thấp chấp nhận đốt một lõi.

❌ Chạm buffer đang thuộc quyền thiết bị trong streaming DMA → ✅ Gỡ ánh xạ hoặc đồng bộ theo DMA API trước; lỗi loại này hỏng dữ liệu rời rạc chứ không crash, nên cực khó tái hiện.

❌ Benchmark read() mà không xoá page cache → ✅ Lần thứ hai gần như luôn trúng cache, và bạn đang đo RAM chứ không đo thiết bị.

❌ Dùng epoll edge-triggered mà đọc một lần rồi quay lại epoll_wait → ✅ Lặp read() tới khi gặp EAGAIN; đọc được ít hơn sức chứa không phải dấu hiệu đã cạn.

❌ Đăng ký file thường vào epoll để "cho khỏi chặn" → ✅ File thường luôn được coi là sẵn sàng; dùng thread riêng hoặc io_uring.

❌ Kỳ vọng zero-copy trong khi bật TLS → ✅ Mã hoá buộc dữ liệu ra user space, đường đi quay về đủ bốn bản sao. Zero-copy mất hẳn chứ không mất một phần.

❌ Nghĩ GPU chạy song song cả hai nhánh if → ✅ Thread cùng warp rẽ hai hướng thì hai nhánh chạy tuần tự; song song thật nằm giữa các warp.

❌ Đo tốc độ kernel GPU rồi kết luận về tốc độ pipeline → ✅ Đo trọn vòng gồm cả hai đầu chép; kernel 4 ms trong pipeline 40 ms nghĩa là 90% thời gian ở chỗ khác.

❌ Thêm thread hoặc thêm GPU khi nút thắt nằm ở tầng dưới → ✅ Bus và thiết bị có trần cứng; thêm worker chỉ tăng tranh chấp. Xác định tầng đang nghẽn trước khi thêm bất cứ thứ gì.

✅ Self-assessment

Bạn đã đạt module này nếu trả lời được:

• Giải thích được CPU điều khiển thiết bị qua thanh ghi thiết bị, memory-mapped I/O và bus PCIe — nếu chưa: bài 01 mục 2, 3 và 4.
• So sánh được polling, interrupt và DMA về việc ai tốn chu kỳ CPU khi dữ liệu di chuyển — nếu chưa: bài 02 mục 2 và 3.
• Lần theo được một lời gọi read() qua syscall, VFS, page cache, block layer và driver tới thiết bị rồi quay về — nếu chưa: bài 03.
• Chọn được mô hình chờ I/O cho server nhiều kết nối dựa trên số fd và chi phí syscall — nếu chưa: bài 04 mục 2 và 3.
• Giải thích được zero-copy loại bỏ những bản sao nào và giới hạn của nó — nếu chưa: bài 05 mục 2, 3 và 4.
• Giải thích được GPU đạt thông lượng cao nhờ đâu — SIMT, băng thông bộ nhớ, đánh đổi độ trễ — nếu chưa: bài 06.
• Chẩn đoán được vì sao một pipeline GPU nghẽn ở khâu chuyển dữ liệu thay vì ở phép tính — nếu chưa: bài 07 mục 4.

Chưa chắc mục nào thì cách kiểm tra thật nhất là lấy một service bạn đang chạy, chạy strace -T lên nó, và tự hỏi mỗi lời gọi đang dừng ở tầng nào trên tuyến đường của bài 03.

🚀 Tiếp theo

Hai module đầu trả lời dữ liệu nằm ở đâu và dữ liệu đi đường nào. Module cuối cùng của khoá đổi sang câu hỏi thực dụng nhất: làm sao biết máy đang nghẽn ở đâu. Bạn sẽ đọc top và htop cho đúng, phân biệt RSS với VSZ, đo I/O bằng iostat, hiểu cgroups chặn tài nguyên container thế nào, và đọc được một lần OOM kill từ dmesg.

Đó cũng là chỗ mọi thứ của hai module trước được đem ra dùng: khi iostat báo độ sâu hàng đợi cao, bạn sẽ biết nó ứng với chặng nào; khi một container bị giết, bạn sẽ biết trang nào đáng lẽ được thu hồi trước.

📚 Tài liệu mở rộng

• Bus-Independent Device Accesses — docs.kernel.org — chuẩn mực cho mọi truy cập MMIO trong kernel.
• Dynamic DMA mapping Guide — docs.kernel.org — coherent so với streaming DMA, IOMMU, bounce buffer.
• NAPI — docs.kernel.org — vì sao mạng tốc độ cao chuyển sang polling.
• Multi-Queue Block IO — docs.kernel.org — hai tầng hàng đợi và cơ chế tag.
• epoll(7) và io_uring_setup(2) — hai man page nên đọc nguyên văn.
• Ringing in a new asynchronous I/O API — LWN — bối cảnh lịch sử vì sao AIO cũ thất bại.
• CUDA C++ Best Practices Guide — chuyển dữ liệu host-device, pinned memory, gộp truy cập bộ nhớ.

Bài tiếp theo: Tổng quan module — Tài nguyên & đo lường