Re: PREEMPT_RT vs ADEOS: the numbers, part 1

[Philippe Gerum <rpm@xenomai.org>]

Karim Yaghmour wrote:
> Sven-Thorsten Dietrich wrote:
> 
>>I am too looking forward to seeing results against the >= 07.48 RT
>>kernels incorporating Daniel's recent IRQ disable relief.
> 
> 
> Indeed, this is on our list.
> 
> 
>>I think the comparison should absolutely compare identical community
>>kernels. The comparison between two different release candidates is
>>questionable. rc2 to rc4 doesn't seem like much, after all, how much
>>code could go into a release candidate. (diff | wc -l) 
>>
>>Also, I question testing -rc code in the first place, except for
>>regression purposes. 
> 
> 
> On this issue, it has to be said that I don't think any set of test
> results will suffice on its own as a definitive benchmark. There will
> be a need for continued testing and publication of said results, which
> we hope others will take part in when we publish the framework we've put
> together.
> 
> 
>>Finally, there are other big-picture issues. How hard is it to maintain
>>the code in general? At the risk of ruffling feathers, forward-porting
>>RT code (or backporting) it a few revisions of rc's isn't too bad. 
>>
>>At Ingo's pace, we have all done some of that.
>>
>>How does that effort compare for porting ADEOS code? If several weeks of
>>work are invested in a comparison of rc2 to rc4, how much additional
>>work is needed to bring Adeos up to the base for the current RT kernel?
> 
> 
> Philippe can correct me if I'm wrong, but adeos maintenance is not that
> difficult. However, it has to be said that up until now, Philippe has been
> the main driving force behind adeos. So while he's been fairly good at
> publishing patches for as recent a kernel as possible, the manpower behind
> PREEMPT_RT is obviously larger. That, though, only requires interested
> parties to participate for it to change. Again, the adeos patch isn't
> that big.
>

Adeos is a faily simple code, only aimed at creating the "pipeline" 
abstraction, which is used to dispatch incoming events to the RT 
extension (which provides the co-scheduler) and Linux, according to 
their respective priorities. I'm going to build a stripped down version 
of the Adeos/x86 patch to only keep the core implementation of the 
interrupt pipeline and post it here asap, so that we could further 
discuss on actual code.

> 
>>In addition, I think the discrepancy between the vanilla kernel and the
>>RT kernel could be much greater, if the workload specifically, or even
>>coincidentally exercised bottlenecks.
> 
> 
> If you've got any specific test run suggestions, we'll gladly take them.
> 
> Karim


-- 

Philippe.