Messages in this thread | | | Date | Wed, 16 Oct 2002 17:23:12 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: epoll (was Re: [PATCH] async poll for 2.5) |
| |
On Wed, 16 Oct 2002, John Gardiner Myers wrote:
> Mark Mielke wrote: > > >Not to enter into any of the other discussions on this issue, I wouldn't > >usually do what you suggest above. [...] if I did I > >a recv() or read() of 2K, and I only received 1K, there is no reason why > >another system call should be invoked on the resource that likely will not > >have any data ready. > > > > > You're into the minutiae here. Sure, you can optimize the read() in > some cases, but Mr. Libenzi's example of a correct code scheme is no > better than mine when it comes to this.
The poll()-like code :
int my_io(...) {
if (poll(...)) do_io(...);
}
The epoll-like code :
int my_io(...) {
while (do_io(...) == EAGAIN) event_wait(...);
}
I would say that the epoll-like code generates less system calls because if you call my_io() by processing small chunks of the I/O space, the epoll-like code will generate only one system call while the poll()-like code two. In case of I/O that ends up in wait the poll()-like code generate two system calls while epoll-like code three. Globally the number of system calls are about the same and from a performance point of view /dev/epoll looks "pretty good" ( see /dev/epoll page ).
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |