[cgl_discussion] libevent & epoll

Eric.Chacron at alcatel.fr Eric.Chacron at alcatel.fr
Thu Aug 14 08:28:50 PDT 2003


>Do you mean HLR, MGC??  soft real-time or hard real-time??
>I don't think we have that kind of tools available for the
>targeted workload.

Whatever the application, but more soft real time.
Yes it can be a MSC for instance.
I have just in mind to compare something like:
1) multi-threaded architectures with one thread per communication object.
2) single thread blocking on select() with multiplexing.
3) AEM single threaded with callback run asynchronously.
4) libevent single threaded ...


Does it make sense for you and where are the bottlenecks ( thread context
switch,
access to chain of events / fd , signal latency ... )  ?



>The way the callback is executed is not really the issue actually. The
>problem is to be able to know how much time it takes to pass the
>information
>to the application.

Indeed, this is the objective to bound this time.
If is use a thread per connection (let's imagine 100 threads with one
socket for each)
i know that the cost (when i receive a message in an interrupt handler in
the TCP stack
to be delivered to the socket owned by the thread) includes a context
switch to that task.
However the context switch on Linux cost in term of CPU cost is low.
So my question about AEM  relates to the event delivery mechanism inside
the kernel ?
If i try to imagine the same scenario replacing the dedicated thread by one
thread with
100 sockets multiplexd on AEM event:
- how is AEM module notified of an incoming message on one socket ( is
there a dedicated kernel thread ...)
- how does it executes the user call back function (in which execution
context ,
  what 's the scheduling policy and priority used for running it  ... ),
- how is managed the multiplexing of event for the thread ... ?

Also it will be usefull to know if there is some compatibility issue (on
AEM) with RT scheduling
policy.


>I don't say that user space libs are not usefull or efficient, I simply
>don't believe that they could solve that problem.


>An event is (like) a process and must be handle as such. So there is one
>execution
>context per event. The context-switch always happens in the context of
>the current
>process so this is not a complete context-switch (as for processes).
>An event can also create a new process and be detached from the parent
>process.

Do you mean by current process the process that's executing the code
that's want to deliver the event ( a kernel thread, a process executing an
interrupt handler,
a process executing a system call ... )  ?
How can the callback be executed in a different task with different memory
mapping ... ?

Eric





"Frederic Rossi (LMC)" <Frederic.Rossi at ericsson.ca>@lists.osdl.org on
08/14/2003 04:12:46 PM

Sent by:    cgl_discussion-admin at lists.osdl.org


To:    Eric CHACRON/FR/ALCATEL at ALCATEL
cc:    "Randy.Dunlap" <rddunlap at osdl.org>, tabmowzo at us.ibm.com,
       mika at osdl.org, cgl_discussion at osdl.org
Subject:    Re: [cgl_discussion] libevent & epoll


Eric.Chacron at alcatel.fr wrote:

>>To compare what??
>>
>>
>Simply compare several sw. architectures based on:
>
>

Do you mean HLR, MGC??  soft real-time or hard real-time??
I don't think we have that kind of tools available for the
targeted workload.

>1) user threads using traditional select() / poll() or SIGIO to get async.
>events
>2) AEM callbacks methods
>3) libevent events called in callback.
>.
>
>
The problem is to know whether we can handle hundred of thousands of
events and keep the real-time profile of apllications.

The way the callback is executed is not really the issue actually. The
problem is to be able to know how much time it takes to pass the
information
to the application. We need an upper
bound on the time it takes for the application to get this information.

Also we want to be able to control this value depending on the platform
requirements (real-time...) and priorities associated with the events.

This is the same kind of problems as for deadlines in real-time scheduling
of processes.

I don't say that user space libs are not usefull or efficient, I simply
don't believe that they could solve that problem.

>PS: I saw in your presentation on AEM that "
>No multithreading; Executes user land call-backs
>from kernel space".
>"User call-backs are executed by context-switching the current process"
>I'm not sure to understand how AEM call back is managed ,
>and how many context switch per event.
>
>
>
An event is (like) a process and must be handle as such. So there is one
execution
context per event. The context-switch always happens in the context of
the current
process so this is not a complete context-switch (as for processes).
An event can also create a new process and be detached from the parent
process.

Frederic

>
>
>
>
>"Frederic Rossi (LMC)" <Frederic.Rossi at ericsson.ca> on 08/14/2003 02:59:34
>PM
>
>To:    Eric CHACRON/FR/ALCATEL at ALCATEL
>cc:    "Randy.Dunlap" <rddunlap at osdl.org>, tabmowzo at us.ibm.com,
>       mika at osdl.org, cgl_discussion at osdl.org
>Subject:    Re: [cgl_discussion] libevent & epoll
>
>
>To compare what?? AEM can be combined with signals, epoll or select.
>
>Each of these mechanisms provides different solutions for different kind
of
>problems. Find
>your problem then you will find your solution.
>
>AEM is proposing one solution for Telecom applications running in the
>context of a carrier-grade Linux as described in
>http://aem.sourceforge.net/reports/AEM_cgl_reqts_draft0.6.pdf
>
>Mika:
>At Ottawa (or a few days before) we also said that if your are satisfied
>with epoll+lib, then just use it.
>
>Frederic
>
>
>
>
>
>
>Eric.Chacron at alcatel.fr wrote:
>
>
>
>>
>>
>>>I think that I mentioned it several months ago.
>>>My faint recollection of it is that the AEM people said that it's not
>>>sufficient, maybe doesn't do task switching fast enough.
>>>
>>>
>>>
>>>
>>Is there any benchmark to compare AEM, libevent , POSIX AIO, SIGIO,
select
>>/poll  () ...
>>for asynchronous events handling ? Then we 'll have a beter understanding
>>on the added value of each one ...
>>
>>
>>
>>
>>"Randy.Dunlap" <rddunlap at osdl.org>@lists.osdl.org on 08/14/2003 05:15:55
>>
>>
>AM
>
>
>>Sent by:    cgl_discussion-admin at lists.osdl.org
>>
>>
>>To:    <tabmowzo at us.ibm.com>
>>cc:    <mika at osdl.org>, <cgl_discussion at osdl.org>
>>Subject:    Re: [cgl_discussion] libevent & epoll
>>
>>
>>
>>
>>
>>
>>>Mika Kukkonen wrote:
>>>
>>>
>>>
>>>
>>>>Re: our Ottawa discussion about AEM and a library on top of /dev/epoll
>>>>
>>>>I have a faint recollection that somebody months ago mentioned this:
>>>>       http://monkey.org/~provos/libevent/
>>>>
>>>>Does anybody still remember why it was not an alternative to AEM?
>>>>
>>>>
>>>>
>>>>
>>>Um, because we forgot it existed?  At least, I don't have any memory of
>>>
>>>
>>>
>>>
>>it.
>>
>>I think that I mentioned it several months ago.
>>My faint recollection of it is that the AEM people said that it's not
>>sufficient, maybe doesn't do task switching fast enough.
>>
>>~Randy
>>
>>
>>
>>_______________________________________________
>>cgl_discussion mailing list
>>cgl_discussion at lists.osdl.org
>>http://lists.osdl.org/mailman/listinfo/cgl_discussion
>>
>>
>>
>>
>>_______________________________________________
>>cgl_discussion mailing list
>>cgl_discussion at lists.osdl.org
>>http://lists.osdl.org/mailman/listinfo/cgl_discussion
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>

_______________________________________________
cgl_discussion mailing list
cgl_discussion at lists.osdl.org
 http://lists.osdl.org/mailman/listinfo/cgl_discussion







More information about the cgl_discussion mailing list