Tao sẽ bất ngờ nếu mày tìm ra được trường hợp nào thực tế mà epoll_wait lại chậm hơn pollấy.
Mày đã né tránh một trong những lý do chính cho sự tồn tại của epoll rồi đấy. Vấn đề của poll (và của select trước đó) là trạng thái của nó chỉ tồn tại trong khi syscall đang thực thi. Nghĩa là, khi mày gọi poll, kernel phải thiết lập giám sát trên tất cả các file descriptor mà mày đã chỉ định, rồi, ngay khi bất kỳ cái nào trong số chúng kích hoạt một event, thì phải dỡ bỏ tất cả các giám sát đó trước khi trả về từ syscall.
Việc thiết lập và dỡ bỏ này có thể chiếm phần lớn thời gian chạy khi các event được nhận thường xuyên. Và khi các event không thường xuyên, điều đó có nghĩa là có thể có một lượng công việc khổng lồ chỉ để trả về một event duy nhất.
epoll thì không làm thế. Chi phí thiết lập và dỡ bỏ chỉ phát sinh khi các file descriptor (hoặc chính xác hơn là các file description liên kết với các descriptor đó) được thêm vào hoặc xóa khỏi tập hợp epoll, chi phí chỉ tỷ lệ thuận với số lượng thay đổi, và chi phí được phân bổ đều theo thời gian. Người ta kỳ vọng rằng một chương trình sẽ quản lý tập hợp epoll ít thường xuyên hơn so với việc chỉ đơn giản là chờ đợi trên nó.
Hơn nữa, vì trạng thái epoll được duy trì ngay cả khi không có syscall epoll nào đang được thực thi, nên kernel có thể đưa các epoll event vào hàng đợi ngay cả khi chương trình đang làm việc khác (nếu mày có nhiều CPU, tất nhiên rồi). Điều đó có nghĩa là có thể có ít việc phải làm hơn vào lần tiếp theo chương trình thực sự gọi epoll_wait.
Vì vậy, sự khác biệt không thực sự nằm ở “số lượng syscall”—thực tế, điều đó thường có thể giống hệt nhau một khi tập hợp epoll đã được thực hiện. Nó nằm ở lượng công việc mà kernel thực hiện cho mỗi syscall.
