[cgl_discussion] AEM analysis summary

Dave Olien dmo at osdl.org
Thu Apr 3 11:11:09 PST 2003


Thanks for reading it and replying.  I'm also just beginning to digest
all your response.  I'll reply to pieces of it in separate mails, and
probably not in order with the content of your reply, if that's OK.
So, some parts of your reply that I'm just deleting for now, I'll
refer to again in later mail.

I'll add, that these responses are my opinions, and others may disagree.

On Thu, Apr 03, 2003 at 10:34:17AM -0500, Frederic Rossi (LMC) wrote:
> 
> 
>     > Since the optimization
>     > is done intrusively in the kernel, the chance for mainline acceptance
>     > is zero. As such, it is more intrusive into the kernel than is
>     > desirable for OSDL.
> 
> 
> What is the acceptable level of "intrusiveness" for OSDL???

In the IDEAL case, an implmentation would not PATCH the kernel at all.
It would be able to do its job using some combination of user mode library,
probably in combination with a loadable kernel module.  The kernel
module would be "well behaved", in the sense that it used only kernel
interfaces that are exported from the kernel, using the EXPORT_SYMBOL
macro.

If some functionality can't be implemented in this way, the next step
would be to examine ways that functionality can be put into the kernel
in a way that can hopefully be accepted into the mainline kernel.
This means the changes should hopefully be small, don't impact kernel
"fast-path" code, and can be justified as having some general purpose,
rather than being tied to your specific application.  Kernel changes are
often times better accepted when they are evolutionary changes.

As a last resort, if a kernel patch is unavoidable, try to make the
patch to code that isn't architecture specific.  Nothing expands the
size of a patch faster than having to include code for every processor
type supported by Linux.

> 
>     > There are also indications that the AEM implementation is still
>     > somewhat of a prototype, as evidenced by some unused code in the
>     > kernel.
> 
> 
> No. AEM is a research project and a work in progress. Plenty of
> work is to be done and all contributions are welcome.

Maybe we can exchange some ideas over the next few days about how
AEM could be modified to reduce its intrusiveness, and consider where
those modifications might lead.

>
>     > A less optimized implementation that accomplishes most of what AEM
>     > implements could be implemented using user-mode libraries and
>     > poll/epoll.
> 
> Less optimized? you mean less capable.
> Because epoll is not a generic mechanism it is a replacement for
> select().Also, I haven't read anything saing that epoll would evolved
> into a generic event mechanism. I'm not even sure it would be desirable.

I'll give this some more thought and we can exchange some ideas,
probably early next week.  Part of being convinced an implementation
a good idea, is to be convinced that the alternatives are not good.

-------- discussion of AEM advantages deleted ------------------------------
> 
> 
> You can download example source code from
> http://sourceforge.net/projects/aem.
> 
> There are simple servers using AEM, AEM+select, AEM+epoll,
> and timers.

Thanks!  I'll look these over.  I had remembered there was some test
code somewhere, but it slipped my mind where.

I'll mail this for now, and come back to the other issues later.



More information about the cgl_discussion mailing list