[cgl_discussion] libevent & epoll
Frederic Rossi (LMC)
Frederic.Rossi at ericsson.ca
Fri Aug 15 04:51:19 PDT 2003
Eric, sorry for the late reply. I think I understood your
previous question now.
There are event handlers in user space, and events in kernel
space. The mechanism used to 'monitor' events in the system
is not based on threads. This is what I said in the presentation.
I think this was your question.
Then, even t if I have 100 sockets or 100.000 I won't have
any threads to handle each of them. In fact, there is no thread
at all. But the mechanism is based on wait queues and the concept
of jobs (simply kernel functions).
Also, events are not multiplexed and there is no event loop to take
care of them.
Event handlers on the other hand can be executed either in the
context of the current process or in a new forked process.
(the first case is much more tested presently - this what I mean
by "single-threaded").
Regarding priorities. Event have priorities associated during
registration. When an event is activated in the kernel, its
priority is used to boost the priority of the process that registered
the event. I added a new variable for this prurpose, which is
not the same as the usual process priority. Then whether it
is a real time task or not, these event priorities are used the same
way. This was for the kernel 2.4. I didn't have on 2.6 for the moment.
Now we are not looking for a global solution that does everything.
For many applications, a multi-threaded and synchronous solution
is the way to go. epoll is already part of the requirements for that
reason. One application could also use epoll for fd's and AEM for
other events, or only epoll, or only AEM or whatever.
Frederic
Eric.Chacron at alcatel.fr wrote:
>
>
>>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