Re: Syslets, Threadlets, generic AIO support, v6


* Ulrich Drepper <drepper@xxxxxxxxxx> wrote:

Ingo Molnar wrote:
3 months ago i verified the published kevent vs. epoll benchmark and
found that benchmark to be fatally flawed. When i redid it properly
kevent showed no significant advantage over epoll.

I'm not going to judge your tests but saying there are no significant
advantages is too one-sided. There is one huge advantage: the
interface. A memory-based interface is simply the best form. File
descriptors are a resource the runtime cannot transparently consume.

yeah - this is a fundamental design question for Linus i guess :-) glibc
(and other infrastructure libraries) have a fundamental problem: they
cannot (and do not) presently use persistent file descriptors to make
use of kernel functionality, due to ABI side-effects. [applications can
dup into an fd used by glibc, applications can close it - shells close
fds blindly for example, etc.] Today glibc simply cannot open a file
descriptor and keep it open while application code is running due to
these problems.

we should perhaps enable glibc to have its separate fd namespace (or
'hidden' file descriptors at the upper end of the fd space) so that it
can transparently listen to netlink events (or do epoll), without
impacting the application fd namespace - instead of ducking to a memory
based API as a workaround.

it is a serious flexibility issue that should not be ignored. The
unified fd space is a blessing on one hand because it's simple and
powerful, but it's also a curse because nested use of the fd space for
libraries is currently not possible. But it should be detached from any
fundamental question of kevent vs. epoll. (By improving library use of
file descriptors we'll improve the utility of all syscalls - by ducking
to a memory based API we only solve that particular event based usage.)

Ingo
-
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/

Relevant Pages

  • Re: epoll gives broken results when interrupted with a signal
    ... >> The epoll is being used to monitor only a handful of file descriptors. ... >> by a parent process, and then passed on to the process doing the epoll. ... domain socket between the two processes. ...
    (Linux-Kernel)
  • Re: epoll and shared fds
    ... resulting file descriptors to P2 through a unix socket. ... P2 registers the received socket in his epollfd. ... Though the documentation says that if a process closes a file ... For epoll, a close is when the kernel file* is released (that is, when all ...
    (Linux-Kernel)
  • Re: Syslets, Threadlets, generic AIO support, v6
    ... Here I think we are forgetting that glibc is userspace and there's no ... So library routines *must not* open file descriptors in the normal space. ... libraries - they'd need to have some kind of separate "private space". ...
    (Linux-Kernel)
  • Re: epoll and shared fds
    ... resulting file descriptors to P2 through a unix socket. ... P2 registers the received socket in his epollfd. ... Though the documentation says that if a process closes a file ... For epoll, a close is when the kernel file* is released (that is, when all ...
    (Linux-Kernel)
  • Re: epoll and fork()
    ... > fd forks? ... > unregisters some file descriptors from the epoll set. ...
    (Linux-Kernel)