[Xenomai-help] [Fwd: Performance decrease]

[Xenomai-help] [Fwd: Performance decrease]

[Philippe Gerum]

-------- Forwarded Message --------
> From: Daniel Schnell <danielsch@domain.hid>
> To: xenomai-help <xenomai@xenomai.org>
> Subject: Performance decrease
> Date: Wed, 30 Aug 2006 11:58:25 -0000
> 
> Hi,
> 
>  
> 
> I have made some CPU throughput tests with/without "Nucleus options->pervasive real-time support in user-space"  enabled/disabled. And the performance dicrease in using that option is for my processor (MPC5200, 400 MHz) about 10%. On the other side I cannot compile RTDM support in without it; the error message when linking vmlinux at the end of the Kernel compile stage is:
> 
>  
> 
> drvlib.c:(.text+0x19f8): undefined reference to `__va_to_kva'
> 
>  
> 
> 
> 
> For what is the real-time support in user space option good for ?
> 
> If it is necessary for RTDM support, shouldn't it be automatically switched on when choosing the RTDM option ?
> 
>  
> 
> 
> 
> 
> 
> I am using ELDK-4.0 + latest 2.4.25-developer kernel from Denx + latest subversion xenomai + adeos patch 1.1-04
> 
>  
> 
> Thanks in advance,
> 
>  
> 
> 
> 
> Ciao,
> 
>  
> 
> Daniel.
> 
-- 
Philippe.

Re: [Xenomai-help] [Fwd: Performance decrease]

[Philippe Gerum]

On Wed, 2006-08-30 at 14:36 +0200, Philippe Gerum wrote:
> -------- Forwarded Message --------
> > From: Daniel Schnell <danielsch@domain.hid>
> > To: xenomai-help <xenomai@xenomai.org>
> > Subject: Performance decrease
> > Date: Wed, 30 Aug 2006 11:58:25 -0000
> > 
> > Hi,
> > 
> >  
> > 
> > I have made some CPU throughput tests with/without "Nucleus options->pervasive real-time support in user-space" 
>  enabled/disabled. And the performance dicrease in using that option is for my processor (MPC5200, 400 MHz) about 10%.

There is an impact induced by activating the user-space support, since
all system calls are filtered through Xenomai; some work is currently
undergoing to reduce this overhead, so that only system calls issued by
Xenomai shadows would be intercepted. This said, out of curiosity, how
do you measure those 10% on your board?

>  On the other side I cannot compile RTDM support in without it; the error message when linking vmlinux
> at the end of the Kernel compile stage is:
> > 
> >  
> > 
> > drvlib.c:(.text+0x19f8): undefined reference to `__va_to_kva'
> > 

I guess that rtdm_mmap_buffer() should be made dependent on
CONFIG_XENO_OPT_PERVASIVE too.

> >  
> > 
> > 
> > 
> > For what is the real-time support in user space option good for ?
> >

This allows running Xenomai applications in user-space, instead of
implementing them as kernel modules.

>  
> > If it is necessary for RTDM support, shouldn't it be automatically switched on when choosing the RTDM option ?
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> > I am using ELDK-4.0 + latest 2.4.25-developer kernel from Denx + latest subversion xenomai + adeos patch 1.1-04
> > 
> >  
> > 
> > Thanks in advance,
> > 
> >  
> > 
> > 
> > 
> > Ciao,
> > 
> >  
> > 
> > Daniel.
> > 
-- 
Philippe.

Re: [Xenomai-help] [Fwd: Performance decrease]

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

Philippe Gerum wrote:
>>  On the other side I cannot compile RTDM support in without it; the error message when linking vmlinux
>> at the end of the Kernel compile stage is:
>>>  
>>>
>>> drvlib.c:(.text+0x19f8): undefined reference to `__va_to_kva'
>>>
> 
> I guess that rtdm_mmap_buffer() should be made dependent on
> CONFIG_XENO_OPT_PERVASIVE too.

True. Will craft some patch.

> 
>>>  
>>>
>>>
>>>
>>> For what is the real-time support in user space option good for ?
>>>
> 
> This allows running Xenomai applications in user-space, instead of
> implementing them as kernel modules.
> 

Everyone planning to write kernel-space drivers and/or applications
should keep an eye on some non-technical aspect as well: the license.
That's no problem for in-house, unpublished work. But for things that
are to be given away / sold, one should recall that the kernel community
is more and more considering non-GPL modules in general as a license
infringement.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] [Fwd: Performance decrease]

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Daniel Schnell wrote:
> Hi,
> 
> 
>>>> For what is the real-time support in user space option good for ?
>>>>
>> This allows running Xenomai applications in user-space, instead of
>> implementing them as kernel modules.
>>
> 
> Everyone planning to write kernel-space drivers and/or applications
> should keep an eye on some non-technical aspect as well: the license.
> That's no problem for in-house, unpublished work. But for things that
> are to be given away / sold, one should recall that the kernel community
> is more and more considering non-GPL modules in general as a license
> infringement.
> 
> 
> Hmm, if I am writing an application that uses Xenomai's magic, e.g. in
> using the POSIX API, that shouldn't violate any GPL code isn't it ? Of
> course a kernel module should be GPL, because it is linked to the GPL
> kernel.

Well, kernel developers have a standard answer: "Consult a lawyer." And
if you are really going for a non-GPL kernel-based product, this is
probably a good idea to assess potential risks. Note that the Xenomai
API in kernel space is GPL due to the GPL environment of the kernel.
Only the user-space libs are LGPL.

> 
> So are RTDM drivers principially running in user space then ?

RTDM drivers are currently running in kernel space only, but they are
providing services to both user and kernel space, symmetrically.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] [Fwd: Performance decrease]

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>>>  On the other side I cannot compile RTDM support in without it; the error message when linking vmlinux
>>> at the end of the Kernel compile stage is:
>>>>  
>>>>
>>>> drvlib.c:(.text+0x19f8): undefined reference to `__va_to_kva'
>>>>
>> I guess that rtdm_mmap_buffer() should be made dependent on
>> CONFIG_XENO_OPT_PERVASIVE too.
> 
> True. Will craft some patch.
> 

Should be fixed in SVN now.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] [Fwd: Performance decrease]

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > On Wed, 2006-08-30 at 14:36 +0200, Philippe Gerum wrote:
 > > -------- Forwarded Message --------
 > > > From: Daniel Schnell <danielsch@domain.hid>
 > > > To: xenomai-help <xenomai@xenomai.org>
 > > > Subject: Performance decrease
 > > > Date: Wed, 30 Aug 2006 11:58:25 -0000
 > > > 
 > > > Hi,
 > > > 
 > > >  
 > > > 
 > > > I have made some CPU throughput tests with/without "Nucleus options->pervasive real-time support in user-space" 
 > >  enabled/disabled. And the performance dicrease in using that option is for my processor (MPC5200, 400 MHz) about 10%.
 > 
 > There is an impact induced by activating the user-space support, since
 > all system calls are filtered through Xenomai; some work is currently
 > undergoing to reduce this overhead, so that only system calls issued by
 > Xenomai shadows would be intercepted. This said, out of curiosity, how
 > do you measure those 10% on your board?

Just being curious: how will you achieve this ? You will make the
function used to dispatch system calls a per-thread pointer ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] [Fwd: Performance decrease]

[Philippe Gerum]

On Thu, 2006-08-31 at 22:41 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > On Wed, 2006-08-30 at 14:36 +0200, Philippe Gerum wrote:
>  > > -------- Forwarded Message --------
>  > > > From: Daniel Schnell <danielsch@domain.hid>
>  > > > To: xenomai-help <xenomai@xenomai.org>
>  > > > Subject: Performance decrease
>  > > > Date: Wed, 30 Aug 2006 11:58:25 -0000
>  > > > 
>  > > > Hi,
>  > > > 
>  > > >  
>  > > > 
>  > > > I have made some CPU throughput tests with/without "Nucleus options->pervasive real-time support in user-space" 
>  > >  enabled/disabled. And the performance dicrease in using that option is for my processor (MPC5200, 400 MHz) about 10%.
>  > 
>  > There is an impact induced by activating the user-space support, since
>  > all system calls are filtered through Xenomai; some work is currently
>  > undergoing to reduce this overhead, so that only system calls issued by
>  > Xenomai shadows would be intercepted. This said, out of curiosity, how
>  > do you measure those 10% on your board?
> 
> Just being curious: how will you achieve this ? You will make the
> function used to dispatch system calls a per-thread pointer ?
> 

Syscalls are just another form of exceptions, so the change will need to
affect all event notifications. A per-thread pointer is an opion
provided there is also a mean to install the callback address, so we
would also need to intercept the Linux task creation event. Another
option would be to define an event filtering routine at domain level,
which gets called before the event is pipelined. The latter is a simple
and straightforward approach which does not change much of the existing
infrastructure, but to remain fast and efficient, the filter should be
defined for the domain which notifies events, and not for the domains
which get notified, and this would be quite restrictive Adeos-wise, even
if this would solve the root issue, Xenomai-wise. To sum up and answer
to your initial question: well, I don't know yet.

-- 
Philippe.

Re: [Xenomai-help] [Fwd: Performance decrease]

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > On Thu, 2006-08-31 at 22:41 +0200, Gilles Chanteperdrix wrote:
 > > Philippe Gerum wrote:
 > >  > On Wed, 2006-08-30 at 14:36 +0200, Philippe Gerum wrote:
 > >  > > -------- Forwarded Message --------
 > >  > > > From: Daniel Schnell <danielsch@domain.hid>
 > >  > > > To: xenomai-help <xenomai@xenomai.org>
 > >  > > > Subject: Performance decrease
 > >  > > > Date: Wed, 30 Aug 2006 11:58:25 -0000
 > >  > > > 
 > >  > > > Hi,
 > >  > > > 
 > >  > > >  
 > >  > > > 
 > >  > > > I have made some CPU throughput tests with/without "Nucleus options->pervasive real-time support in user-space" 
 > >  > >  enabled/disabled. And the performance dicrease in using that option is for my processor (MPC5200, 400 MHz) about 10%.
 > >  > 
 > >  > There is an impact induced by activating the user-space support, since
 > >  > all system calls are filtered through Xenomai; some work is currently
 > >  > undergoing to reduce this overhead, so that only system calls issued by
 > >  > Xenomai shadows would be intercepted. This said, out of curiosity, how
 > >  > do you measure those 10% on your board?
 > > 
 > > Just being curious: how will you achieve this ? You will make the
 > > function used to dispatch system calls a per-thread pointer ?
 > > 
 > 
 > Syscalls are just another form of exceptions, so the change will need to
 > affect all event notifications. A per-thread pointer is an opion
 > provided there is also a mean to install the callback address, so we
 > would also need to intercept the Linux task creation event. 

If we continue on this idea. PTD initialization already intercept the
Linux task creation event to set the PTDs to 0. Maybe we could dedicate
a PTD to mean that a thread is "monitored", so that when an Adeos event
occurs, the event only triggers Xenomai callbacks if the thread is
monitored (not sure that it would work for the "schedule" event
though).

But there is an exception: the "bind" syscall event must be intercepted
for threads that are not yet marked as monitored.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] [Fwd: Performance decrease]

[Philippe Gerum]

On Fri, 2006-09-01 at 14:54 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > On Thu, 2006-08-31 at 22:41 +0200, Gilles Chanteperdrix wrote:
>  > > Philippe Gerum wrote:
>  > >  > On Wed, 2006-08-30 at 14:36 +0200, Philippe Gerum wrote:
>  > >  > > -------- Forwarded Message --------
>  > >  > > > From: Daniel Schnell <danielsch@domain.hid>
>  > >  > > > To: xenomai-help <xenomai@xenomai.org>
>  > >  > > > Subject: Performance decrease
>  > >  > > > Date: Wed, 30 Aug 2006 11:58:25 -0000
>  > >  > > > 
>  > >  > > > Hi,
>  > >  > > > 
>  > >  > > >  
>  > >  > > > 
>  > >  > > > I have made some CPU throughput tests with/without "Nucleus options->pervasive real-time support in user-space" 
>  > >  > >  enabled/disabled. And the performance dicrease in using that option is for my processor (MPC5200, 400 MHz) about 10%.
>  > >  > 
>  > >  > There is an impact induced by activating the user-space support, since
>  > >  > all system calls are filtered through Xenomai; some work is currently
>  > >  > undergoing to reduce this overhead, so that only system calls issued by
>  > >  > Xenomai shadows would be intercepted. This said, out of curiosity, how
>  > >  > do you measure those 10% on your board?
>  > > 
>  > > Just being curious: how will you achieve this ? You will make the
>  > > function used to dispatch system calls a per-thread pointer ?
>  > > 
>  > 
>  > Syscalls are just another form of exceptions, so the change will need to
>  > affect all event notifications. A per-thread pointer is an opion
>  > provided there is also a mean to install the callback address, so we
>  > would also need to intercept the Linux task creation event. 
> 
> If we continue on this idea. PTD initialization already intercept the
> Linux task creation event to set the PTDs to 0. Maybe we could dedicate
> a PTD to mean that a thread is "monitored", so that when an Adeos event
> occurs, the event only triggers Xenomai callbacks if the thread is
> monitored

The advantage I see with wiring the callback into the task struct is
that it should be easier to handle the binding issue. While we are at
it, we could just define an additional callback pointer, no need to
recycle ptds.

>  (not sure that it would work for the "schedule" event
> though).

We want to know all scheduling events anyway, including those involving
non-shadows, so that we can make the root thread inherit the right
priority (and also engage the interrupt shield as needed).

> 
> But there is an exception: the "bind" syscall event must be intercepted
> for threads that are not yet marked as monitored.

That's the major issue. We need to keep events flowing to a filtering
callback in order to detect binding ops, but without going through the
entire pipeline abstraction. And pipelining as it is now must be kept
for bound Linux tasks, i.e. shadows. The idea is to save the time spent
in the Adeos event dispatcher for tasks that don't need to tell the
world about what they are actually doing.

-- 
Philippe.

Re: [Xenomai-help] [Fwd: Performance decrease]

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > > 
 > > But there is an exception: the "bind" syscall event must be intercepted
 > > for threads that are not yet marked as monitored.
 > 
 > That's the major issue. We need to keep events flowing to a filtering
 > callback in order to detect binding ops, but without going through the
 > entire pipeline abstraction. And pipelining as it is now must be kept
 > for bound Linux tasks, i.e. shadows. The idea is to save the time spent
 > in the Adeos event dispatcher for tasks that don't need to tell the
 > world about what they are actually doing.

The binding operation could be made a standard Linux operation, such as
an ioctl for instance.

-- 


					    Gilles Chanteperdrix.

[Xenomai-core] Re: [Xenomai-help] [Fwd: Performance decrease]

[Philippe Gerum]

On Fri, 2006-09-01 at 16:58 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > > 
>  > > But there is an exception: the "bind" syscall event must be intercepted
>  > > for threads that are not yet marked as monitored.
>  > 
>  > That's the major issue. We need to keep events flowing to a filtering
>  > callback in order to detect binding ops, but without going through the
>  > entire pipeline abstraction. And pipelining as it is now must be kept
>  > for bound Linux tasks, i.e. shadows. The idea is to save the time spent
>  > in the Adeos event dispatcher for tasks that don't need to tell the
>  > world about what they are actually doing.
> 
> The binding operation could be made a standard Linux operation, such as
> an ioctl for instance.
> 

Yes. We would have to define another character device node, but since we
are going to need this for Xenomai3, we would only be anticipating the
requirement anyway.

PS: moving this discussion to xenomai-core.

-- 
Philippe.