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

[Eric Dumazet]

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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/