Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

Eric Dumazet
2007-02-27T16:58:27Z

On Tuesday 27 February 2007 17:21, Evgeniy Polyakov wrote:
> I probably selected wrong words to desribe, here is in details how
> kevent differs from epoll.
>
> Polling case need to perform additional check before event can be copied
> to userspace, that check must be done for each even being copied.
> Kevent does not need that (it needs it for poll emulation) - if event is
> ready, then it is ready.
>
> sys_poll() create a wait queue where different events (callbacks for
> them) are stored, when driver calls wake_up() appropriate event is added
> to the ready list and calls wake_up() for that wait queue, which in turn
> calls ->poll for each event and transfer it to userspace if it is ready.
>
> Kevent works slightly different - it does not perform additional check
> for readiness (although it can, and it does in poll notifications), if
> event is marked as ready, parked in waiting syscal thread is awakened
> and event is copied to userspace.
> Also waiting syscall is awakened through one queue - event is added
> and wake_up() is called, while in epoll() there are two queues.

Thank you Evgeniy for this comparison. poll()/select()/epoll() are tricky
indeed.

I believe one advantage of epoll is it uses standard mechanism (mandated for
poll()/select() ), while kevent adds some glue and kevent_storage in some
structures (struct inode, struct file, ...), thus adding some extra code and
extra storage in hot paths. Yes there might be a gain IF most users of these
path want kevent. But other users pay the price (larger kernel code and
data), that you cannot easily bench.

Using or not epoll has nearly zero cost over standard kernel (only struct file
has some extra storage)