Messages in this thread | | | Date | Wed, 05 Jun 2013 16:41:48 +0300 | From | Eliezer Tamir <> | Subject | Re: [PATCH v9 net-next 5/7] net: simple poll/select low latency socket poll |
| |
On 05/06/2013 16:30, Eric Dumazet wrote: > On Wed, 2013-06-05 at 13:34 +0300, Eliezer Tamir wrote: >> A very naive select/poll busy-poll support. >> Add busy-polling to sock_poll(). >> When poll/select have nothing to report, call the low-level >> sock_poll() again until we are out of time or we find something. >> Right now we poll every socket once, this is suboptimal >> but improves latency when the number of sockets polled is not large. >> >> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> >> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> >> Tested-by: Willem de Bruijn <willemb@google.com> >> Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com> >> --- > > I am a bit uneasy with this one, because an applicatio polling() on one > thousand file descriptors using select()/poll(), will call sk_poll_ll() > one thousand times.
But we call sk_poll_ll() with nonblock set, so it will only test once for each socket and not loop.
I think this is not as bad as it sounds. We still honor the time limit on how long to poll.
When we busy-wait on a single socket we call sk_poll_ll() repeatedly until we timeout or we have something to report.
Here on the other hand, we sk_poll_ll() once for each file, so we loop on the files. We moved the loop from inside sk_poll_ll to select/poll.
I also plan on improving this this in the next stage.
The plan is to give control on whether sk_poll_ll is called to select/poll/epoll, so the caller has even more control.
-Eliezer
| |