Re: [Xenomai-core] rt_queue_create in RT task?
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt_queue_create in RT task?
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@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_queue_create in RT task?
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@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_queue_create in RT task?
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@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_queue_create in RT task?
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_queue_create in RT task?
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@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_queue_create in RT task?
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_queue_create in RT task?
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
