There are at least 2 benefits over POLL->READ 1. Reduce a little complexity of user code, and save lots of sqes. 2. Better performance. Users can’t if an operation will block without issuing an extra O_NONBLOCK syscall, which ends up with always using POLL->READ link. If it’s handled by kernel, we may only poll when we know it’s needed. > 2020年2月15日 上午9:10，Jens Axboe <axboe@xxxxxxxxx> 写道： > > On 2/14/20 5:16 PM, Carter Li 李通洲 wrote: >> Hello Jens, >> >> >>> It's now up to 3.5x the original performance for the single client case. >>> Here's the updated patch, folded with the original that only went half >>> the way there. >> >> >> I’m looking forward to it. >> >> And question again: since POLL->READ/RECV is much faster then READ/RECV async, >> could we implement READ/RECV that would block as POLL->READ/RECV? Not only for >> networking, but also for all pollable fds. > > That's exactly the next step. With this, we have a very efficient way of > doing async IO for anything that can be driven by poll. Then we can do it > by default, instead of doing an async punt. Much faster and much more > efficient. > > I'll try and work on that next week, I think this could be a real game > changer. > > -- > Jens Axboe
