On Sat, Jun 1, 2024 at 00:38:49 -0700, Christoph Hellwig wrote: >On Fri, May 31, 2024 at 05:10:15PM +0800, hexue wrote: >> Here's a misconfigured if application is doing polled IO >> for devices that don't have a poll queue, the process will >> continue to do syscall between user space and kernel space, >> as in normal poll IO, CPU utilization will be 100%. IO actually >> arrives through interruption. >> >> This patch returns a signal that does not support the operation >> when the underlying device does not have a poll queue, avoiding >> performance and CPU simultaneous loss. > >This feels like the wrong place to check for this. > >As we've dropped synchronous polling we now only support >thead based polling, right now only through io_uring. > >So we need to ensure REQ_POLLED doesn't even get set for any >other I/O. Sorry I'm not entirely clear on the impact of REQ_POLLED in this context. I searched that REQ_POLLED is set for request if polled in io_uring or io_uring_cmd, but here we just judge the state of request_queue. Do you mean making this judgment here may not be a good choice, because it may affect other IO (by same path), and this change should be just targeted at io_uring?
