Re: [PATCH 5/6] syslets: add generic syslets infrastructure

From: Davide Libenzi
Date: Wed Jan 09 2008 - 18:16:06 EST


On Thu, 10 Jan 2008, Rusty Russell wrote:

> On Thursday 10 January 2008 05:16:57 Zach Brown wrote:
> > > The latter. A ring is optimal for processing a huge number of requests,
> > > but if you're really going to be firing off syslet threads all over the
> > > place you're not going to be optimal anyway. And being able to point the
> > > return value to the stack or into some datastructure is way nicer to code
> > > (zero setup == easy to understand and easy to convert).
> >
> > One of Linus' rhetorical requirements for the syslets work is that we be
> > able to wait for the result without spending overhead building up state
> > in some completion context. The userland rings in the current syslet
> > patches achieve that and don't seem outrageously complicated.
>
> I'd have to read his original statement, but eventfd doesn't build up state,
> so I think it qualifies.

I think you and Zach are talking about different issues ;)
Eventfd born for two different reasons. First, to be able to have
userspace to signal to a poll/select/epoll based listener an event. This
can elso be done with pipes, but eventfd has a few advantages over pipes
(3-4 times faster and *a lot* less memory footprint). Second, as a generic
way for kernel subsystems to signal completions to a poll/select/epoll
userspace listener. And this is what is used in the new KAIO eventfd
feature (patch was like 5 lines IIRC).
This allow for KAIO events to be signaled to poll/select/epoll in a pretty
easy way, using a simple extension of the AIO API.
What we talked originally with Ingo, when the first syslet code came up,
was the ability to do the reverse thing. That is, host an epoll_wait()
inside a syslet, and gather the completion using whatever the syslet code
was/is going to use for it.
Given that 1) the eventfd completion patch was trivial and immediately
available 2) the future of the whole syslet concept was/is still unclear,
I believe it makes/made sense. If the syslets will become mainline, it'll
mean that userspace will then be able to select the event-completion
"hosting" method that better suits their needs. That are, either AIO
completion hosted inside an epoll_wait() via an eventfd, or an
epoll_wait() hosted inside a syslet.




- Davide


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