On Mon, Aug 12, 2024 at 06:19:35AM -0700, Christoph Hellwig wrote: > On Mon, Aug 12, 2024 at 12:57:07PM +0000, Joe Damato wrote: > > From: Martin Karsten <mkarsten@xxxxxxxxxxxx> > > > > Setting prefer_busy_poll now leads to an effectively nonblocking > > iteration though napi_busy_loop, even when busy_poll_usecs is 0. > > Hardcoding calls to the networking code from VFS code seems like > a bad idea. Not that I disagree with the concept of disabling > interrupts during busy polling, but this needs a proper abstraction > through file_operations. Thanks for the feedback; the code modified in the this patch was already calling directly into the networking stack; we didn't add that call. We added a check on another member of the eventpoll structure, though. In general: it may be appropriate for a better abstraction to exist between fs/eventpoll.c and the networking stack as there are already many calls into the networking stack from this code. However, I think that is a much larger change that is not directly related to what we're proposing, which is: a mechanism for more efficient epoll-based busy poll which shows significant performance improvements. - Joe
