[Xenomai-core] rt_queue_create in RT task?

[Xenomai-core] rt_queue_create in RT task?

[Andreas Glatz]

Hi,

Calling rt_queue_create in a real-time task is supposed to fail
according to the documentation. 

I found out, that the reason for this is, that the memory for 
the queue memory pool is allocated with vmalloc/kmalloc. 
Is there another reason?

I still would like to be able to call rt_queue_create in a 
real-time task in my activity of porting real-time applications
to Xenomai because I think that patching rt_queue_create would
be less time consuming than redesigning the applications.

My approach to get there would be to split rt_queue_create into 
two separate functions, one that allocates the memory pool
and another one which initializes the queue structure... 

Best regards,
Andreas


 

Re: [Xenomai-core] rt_queue_create in RT task?

[Steven Seeger]

Andreas,

I do not know your situation but it is generally better to not  
allocate things in realtime contexts because it is not deterministic.  
You may consider redesigning your applications to use pre-allocated  
queues as it would be better overall.

Regards,
Steven

On Mar 9, 2009, at 10:20 AM, Andreas Glatz wrote:

> Hi,
>
> Calling rt_queue_create in a real-time task is supposed to fail
> according to the documentation.
>
> I found out, that the reason for this is, that the memory for
> the queue memory pool is allocated with vmalloc/kmalloc.
> Is there another reason?
>
> I still would like to be able to call rt_queue_create in a
> real-time task in my activity of porting real-time applications
> to Xenomai because I think that patching rt_queue_create would
> be less time consuming than redesigning the applications.
>
> My approach to get there would be to split rt_queue_create into
> two separate functions, one that allocates the memory pool
> and another one which initializes the queue structure...
>
> Best regards,
> Andreas
>
>
>
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] rt_queue_create in RT task?

[Andreas Glatz]

Hi,

On Mon, 2009-03-09 at 10:36 -0400, Steven Seeger wrote:
> Andreas,
> 
> I do not know your situation but it is generally better to not  
> allocate things in realtime contexts because it is not deterministic.

Of course :) So my plan is to preallocate the memory for the
memory pool of all queues, for example with rt_heap_create.
To follow the example, I would pass the reference of the RT_HEAP
object to rt_queue_create which would call rt_heap_alloc to get 
the memory for its queue memory pool. Using RT_HEAP would create some
additional overhead, which currently doesn't worry me too much. 


> You may consider redesigning your applications to use pre-allocated  
> queues as it would be better overall.

Agreed. I consider it as last resort.

> 
> Regards,
> Steven

Thanks,
Andreas

> 
> On Mar 9, 2009, at 10:20 AM, Andreas Glatz wrote:
> 
> > Hi,
> >
> > Calling rt_queue_create in a real-time task is supposed to fail
> > according to the documentation.
> >
> > I found out, that the reason for this is, that the memory for
> > the queue memory pool is allocated with vmalloc/kmalloc.
> > Is there another reason?
> >
> > I still would like to be able to call rt_queue_create in a
> > real-time task in my activity of porting real-time applications
> > to Xenomai because I think that patching rt_queue_create would
> > be less time consuming than redesigning the applications.
> >
> > My approach to get there would be to split rt_queue_create into
> > two separate functions, one that allocates the memory pool
> > and another one which initializes the queue structure...
> >
> > Best regards,
> > Andreas
> >
> >
> >
> >
> > _______________________________________________
> > Xenomai-core mailing list
> > Xenomai-core@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 

Re: [Xenomai-core] rt_queue_create in RT task?

[Steven Seeger]

I do not have Xenomai code in front of me, but I see no reason why  
this should be a problem but I don't have Xenomai code easily  
accessible right now so I can't provide any further insight.

Steven

Re: [Xenomai-core] rt_queue_create in RT task?

[Philippe Gerum]

Andreas Glatz wrote:
> Hi,
> 
> Calling rt_queue_create in a real-time task is supposed to fail
> according to the documentation. 
>

It fails from kernel space, otherwise, from user-space, your application would 
simply be moved to a Linux context automatically for processing the 
rt_queue_create() syscall.

> I found out, that the reason for this is, that the memory for 
> the queue memory pool is allocated with vmalloc/kmalloc. 
> Is there another reason?
> 

No, that's the main reason, along with other Linux memory management ops to map 
the pool to user-space if Q_SHARED is passed.

> I still would like to be able to call rt_queue_create in a 
> real-time task in my activity of porting real-time applications
> to Xenomai because I think that patching rt_queue_create would
> be less time consuming than redesigning the applications.
> 

You mean that it would be faster to hack rt_queue_create() than moving your 
real-time code to userland? Well, probably, fair enough. However, you will 
probably lose much more time debugging your port from kernel space than it would 
have cost you to move it to user-space and benefit from the GDB support there. YMMV.

> My approach to get there would be to split rt_queue_create into 
> two separate functions, one that allocates the memory pool
> and another one which initializes the queue structure... 
>

Then don't work at RT_HEAP level, but rather manipulate the internal xnheap 
object from the RT_QUEUE descriptor instead (bufpool). You would basically have 
to change the bufpool field to become a pointer to the actual heap object, and 
keep the rest unchanged.

> Best regards,
> Andreas
> 
> 
>  
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

Re: [Xenomai-core] rt_queue_create in RT task?

[Andreas Glatz]

Hi,

On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
> Andreas Glatz wrote:
> > Hi,
> > 
> > Calling rt_queue_create in a real-time task is supposed to fail
> > according to the documentation. 
> >
> 
> It fails from kernel space, otherwise, from user-space, your application would 
> simply be moved to a Linux context automatically for processing the 
> rt_queue_create() syscall.

Currently, we are developing in Userspace, so everything works fine. But
we still would like to have the option to run in kernel-space if for
some reason the user-space performance is too poor. 

> 
> > I found out, that the reason for this is, that the memory for 
> > the queue memory pool is allocated with vmalloc/kmalloc. 
> > Is there another reason?
> > 
> 
> No, that's the main reason, along with other Linux memory management ops to map 
> the pool to user-space if Q_SHARED is passed.

That's great :)

> 
> > I still would like to be able to call rt_queue_create in a 
> > real-time task in my activity of porting real-time applications
> > to Xenomai because I think that patching rt_queue_create would
> > be less time consuming than redesigning the applications.
> > 
> 
> You mean that it would be faster to hack rt_queue_create() than moving your 
> real-time code to userland? Well, probably, fair enough. However, you will 
> probably lose much more time debugging your port from kernel space than it would 
> have cost you to move it to user-space and benefit from the GDB support there. YMMV.

We have a Makefile based build system which generates a user-space
executable or a kernel-space module. The legacy code which I am porting
was written in C++. I had to add some "glue" code for being able to add
C++ code to a kernel module (don't tell Linus about it ;). The Xenomai
layer of the C++ part uses native API calls which are available both in
user- and kernel-space.
 
We decided to develop the application in user-space and after we are bug
free, we are thinking to move it to kernel space to compare the
performance of the application running in user- and kernel-space.

Everything works fine so far and we can switch between running in
user-space and kernel-space without any problems except that we are not
able to create RT_QUEUES in tasks in kernel-space. 

I'm convinced, that we never would have gotten that far without Xenomai
and it's very consistent and streamlined API!

> 
> > My approach to get there would be to split rt_queue_create into 
> > two separate functions, one that allocates the memory pool
> > and another one which initializes the queue structure... 
> >
> 
> Then don't work at RT_HEAP level, but rather manipulate the internal xnheap 
> object from the RT_QUEUE descriptor instead (bufpool). You would basically have 
> to change the bufpool field to become a pointer to the actual heap object, and 
> keep the rest unchanged.

Thank you for this tip!!


Regards, 
Andreas

Re: [Xenomai-core] rt_queue_create in RT task?

[Philippe Gerum]

Andreas Glatz wrote:
> Hi,
> 
> On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
>> Andreas Glatz wrote:
>>> Hi,
>>>
>>> Calling rt_queue_create in a real-time task is supposed to fail
>>> according to the documentation. 
>>>
>> It fails from kernel space, otherwise, from user-space, your application would 
>> simply be moved to a Linux context automatically for processing the 
>> rt_queue_create() syscall.
> 
> Currently, we are developing in Userspace, so everything works fine. But
> we still would like to have the option to run in kernel-space if for
> some reason the user-space performance is too poor. 
>

Could you elaborate a bit about this? What was bad, latency? If so, what is your 
target arch/platform, and which typical latency do you require?

-- 
Philippe.

Re: [Xenomai-core] rt_queue_create in RT task?

[Andreas Glatz]

Hi,

On Mon, 2009-03-09 at 18:02 +0100, Philippe Gerum wrote:
> Andreas Glatz wrote:
> > Hi,
> > 
> > On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
> >> Andreas Glatz wrote:
> >>> Hi,
> >>>
> >>> Calling rt_queue_create in a real-time task is supposed to fail
> >>> according to the documentation. 
> >>>
> >> It fails from kernel space, otherwise, from user-space, your application would 
> >> simply be moved to a Linux context automatically for processing the 
> >> rt_queue_create() syscall.
> > 
> > Currently, we are developing in Userspace, so everything works fine. But
> > we still would like to have the option to run in kernel-space if for
> > some reason the user-space performance is too poor. 
> >
> 
> Could you elaborate a bit about this? What was bad, latency? If so, what is your 
> target arch/platform, and which typical latency do you require?
> 

Interrupt latency is an issue. But we are still in the development phase
and I don't have detailed figures available. I'll post them when I get
them!

Thanks for yr help,
Andreas