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

Zhuang, Louis louis.zhuang at intel.com
Thu Jul 10 18:59:20 PDT 2003


Dear Ibrahim/Andre
	Thanks for your knowledgeable reply, please see my comments.

> -----Original Message-----
> From: Ibrahim Haddad (QB/LMC) [mailto:ibrahim.haddad at ericsson.com]
> Sent: Thursday, July 10, 2003 10:13 PM
> 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 ?
[Louis] As I read the spec SCL.1.0, I think the item bundles scalability
requirement with asynchronous mechanism. Only AEM can fulfill such item,
so... 

> 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.
[Louis] We get a total agreement here.

> 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.
[Louis] IMHO, parallelizability and resource sharing depends on the
nature of application, not system. If some unnecessary shared
resources/locks in system break the parallelizability, we need 1)
remove/avoid the bottleneck in system like epoll, or 2) find another way
to resolve the issue like AEM 

> 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".
[Louis] AFAIK, epoll has perfect O(1)/linear performance on enormous
channels. I cannot see any system bottleneck here. AEM is also linear
according to its design. Of course, a bad application produces other
bottlenecks, but that's issue in application or programming model.

> 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".
[Louis] again, system should not know which resource of an event is
shared with another resource. It's application's business. Only system
should guarantee no bottleneck in system will prevent itself from
delivering events efficiently.  

> 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.
[Louis] Agree. Event priority instead of thread priority is more
important. But my question is, in your typical environment, do all
events for the same channel have the same priority? Or else, might each
event have different priority in the same channel? If latter, I admit it
is really advantage of AEM because it has potential to implement
event-type-based priority. Let's go details?

> 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.
[Louis] Totally agree. So the real requirement is 'scalability of
system', but the method is under discussing. In requirement spec, we
should not appoint any implementation or programming model.




More information about the cgl_discussion mailing list