@
zizon 破案了,确实是这个问题,Linux 提供的 benchmark 有问题,只有 1 个 writer 不能够喂饱这么多 reader ,导致 reader 等待,造成频繁的 context switch 。[我改了下 benchmark](
https://github.com/pwrliang/linux/blob/master/tools/perf/bench/epoll-wait.c),现在每个线程都能够达到 60w 的 throughput
```
./perf bench epoll wait -t 14 -r 2 -w 14 -m
# Running 'epoll/wait' benchmark:
Run summary [PID 5905]: 14 threads monitoring on 64 file-descriptors for 2 secs.
[thread 0] fdmap: 0x1aec590 ... 0x1aec68c [ 648960 ops/sec ]
[thread 1] fdmap: 0x1aec920 ... 0x1aeca1c [ 640540 ops/sec ]
[thread 2] fdmap: 0x1aeccb0 ... 0x1aecdac [ 635712 ops/sec ]
[thread 3] fdmap: 0x1aed040 ... 0x1aed13c [ 650944 ops/sec ]
[thread 4] fdmap: 0x1aed3d0 ... 0x1aed4cc [ 638048 ops/sec ]
[thread 5] fdmap: 0x1aed760 ... 0x1aed85c [ 648064 ops/sec ]
[thread 6] fdmap: 0x1aedaf0 ... 0x1aedbec [ 632416 ops/sec ]
[thread 7] fdmap: 0x1aede80 ... 0x1aedf7c [ 647144 ops/sec ]
[thread 8] fdmap: 0x1aee210 ... 0x1aee30c [ 628896 ops/sec ]
[thread 9] fdmap: 0x1aee5a0 ... 0x1aee69c [ 634521 ops/sec ]
[thread 10] fdmap: 0x1aee930 ... 0x1aeea2c [ 640032 ops/sec ]
[thread 11] fdmap: 0x1aeecc0 ... 0x1aeedbc [ 626093 ops/sec ]
[thread 12] fdmap: 0x1aef050 ... 0x1aef14c [ 645843 ops/sec ]
[thread 13] fdmap: 0x1aef3e0 ... 0x1aef4dc [ 643849 ops/sec ]
Averaged 640075 operations/sec (+- 0.33%), total secs = 2
```