[cgl_discussion] RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec

Fan, Ardelle ardelle.fan at intel.com
Thu Jul 10 18:56:13 PDT 2003


Hi Ibrahim and Andre

Thanks for your comments.
You must know that all our discussion about SCL.1.0 is not aim to lower any Poc AEM or Epoll.
Both AEM and Epoll has its strong point as well as weakness. Since AEM split the event waiting thread into kernel space "job", it really minimize the amount of "shared resource" among those activities. From this point it has better performance. But its "invasion" into kernel makes things complex. And currently stability is still its sword of Damocles.
If using Epoll, event handler dispatching in user space of cause weakens its responsiveness. But it is already in kernel and its kernel implementation is light weight, so that it is more acceptable for distro.
Per our analysis, both AEM and Epoll have potential, if not capability, to meet requirement. We just want to refine the requirement description to make both AEM and Epoll satisfy. For distro, they can choose either Poc according to their concern, performance or stability. I think requirement should balance between them.

Regards/Ardelle


-----Original Message-----
From: Ibrahim Haddad (QB/LMC) [mailto:ibrahim.haddad at ericsson.com]
Sent: 2003?7?10? 22:13
To: Zhuang, Louis
Cc: Fan, Ardelle; CGL Discussion; Linda Bebernes; Andre Beliveau (QB/LMC)
Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec


Hi Louis,

Sorry for late reply. Frederic is on vacation so Andre Beliveau
from our group is following up since he is very familiar with AEM.

Here's his feedback:

----
Hi, 

I went through the CGL spec, and I have not found any reference to the 
detailed implementation. Can you indicate the specific points that lead 
you to believe that implementation choices are explicit in the spec ?

Regarding Epoll, you can read more about the comparison between Epoll 
and AEM at the following address 
( http://heanet.dl.sourceforge.net/sourceforge/aem/aem-faq-draf0.3.pdf )


The essential requirements are scalability (by providing asynchronous
events ("threads") and "soft real-time" responsiveness.

Scalability is very important.  By scalability we don't simply mean the
capability to increase the ability of the system to cope with more input, but
more importantly, the ability to "linearly" increase this capacity.  To achieve
this, we need to
a) parallelize the activities (threads) to the largest extent
b) minimize the amount of "shared resource" among those activities.

Even if you have a "not so linear" scalable mechanism, you will see
impact on performance only when you reach the capacity of the system 
where contention on those "shared resources" occur.  This is why we 
talk about "System scalability for large number of events".

This brings me to the second requirement: "soft real-time" responsiveness.
It is related to scalability because the response time under low load is
generally good.  To get good response times under high load, (again), you 
need to have a minimum of "shared resources".

When handling events, if you have multiple events being monitored by 
the same thread, all events are inheriting the priority of the thread.
In an event based system, the type of event should guide the priority
of execution for it, not the priority of the thread monitoring those events.

One should note that this scalability issue is not only an application
designe issue.  It starts by providing at the kernel level the basis
for such scalability.  If the kernel has some resource contention, the
whole system will not be "linearly" scalable.  Therefore, when we specify
that we want "Provide Linux kernel with the capability to handle 
such kind of events", we mean that the kernel mechanisms must also 
be scalable.


Regards, Andre Beliveau
--

Thank you,
Ibrahim

> -----Original Message-----
> From: Zhuang, Louis [mailto:louis.zhuang at intel.com]
> Sent: Wednesday, July 09, 2003 12:13 PM
> To: Ibrahim Haddad (QB/LMC)
> Cc: Fan, Ardelle; CGL Discussion; Linda Bebernes
> Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec
> 
> 
> Dear Ibrahim,
> 	If I understand the paper rightly, the real requirement is
> "scalability in enormous events", and the asynchronous mechanism or
> multi-threading are all "common ideas" to resolve the issue, right?
> According to the paper, weakness of epoll is its focus on 
> descriptor. So
> my questions are,
> 
> 1. If "asynchronous mechanism" is just a solution for real 
> requirement,
> is it absolutely necessary to put the implementation choice in spec?
>     
> 2. epoll can only process descriptors... but as you know, 
> descriptor can
> represent almost everything in Unices (sockets, files, pipes 
> and devices
> etc.). Is it a real weakness?
> 
> Perhaps I lose some key points which demonstrate AEM's 
> strength such as
> 'soft realtime'. But I think we need an agreement on 
> definition in 'soft
> RT' here. Any comments?
>   - Louis 
> 
> > -----Original Message-----
> > From: Ibrahim Haddad (QB/LMC) [mailto:ibrahim.haddad at ericsson.com]
> > Sent: Wednesday, July 09, 2003 11:07 PM
> > To: Zhuang, Louis
> > Cc: Fan, Ardelle; CGL Discussion; Linda Bebernes
> > Subject: RE: [cgl_specs] Proposal to change SCL.1.0 in CGL_Req spec
> > 
> > Hi Louis,
> > 
> > I think the attached article will provide you with the answer.
> > It provides the background on why we need something like aem,
> > and to meet which requirements.
> > 
> > Thanks,
> > Ibrahim
> > 
> > ps: the zip file contains 1 html file + 2 png figures.
> 




More information about the cgl_discussion mailing list