Hello,

I'm using a Linux userspace application with Libmetal to communicate core 0 (Linux) and core 1 (FreeRTOS) in a Zynq 7000. The application is very simple, as it only forwards messages between cores and works very well, but I have noticed that it creates an additional thread automatically. I suspect this is because of Libmetal, as OpenAMP's wiki states:

"The Linux userspace implementation will use a thread to call select() function to listen to the file descriptors of the devices to see if there is an interrupt triggered. If there is an interrupt triggered, it will call the interrupt handler registered by the user application."

However, I was planning system priorities to configure the userspace watchdog daemon and noticed that this thread has SCHED_FIFO scheduling policy with a priority of 99 (the highest possible). This priority is above all my userspace applications, including the watchdog daemon, and even above several kernel threads, which worries me.

The code responsible for this behavior is inside libmetal/lib/system/linux/irq.c, function metal_linux_irq_handling(void * args):

param.sched_priority = sched_get_priority_max(SCHED_FIFO);

/* Ignore the set scheduler error */

ret = sched_setscheduler(0, SCHED_FIFO, &param);

My question is: can I lower the priority of this thread? If the answer is yes, what would be the minimum required priority for Libmetal to operate properly?

Thank you very much and best regards,

Eduardo.

Eduardo Viruete

Software Engineer

Teltronic

Tel: +34 976 465656 Ext. 313

http://www.teltronic.es/ www.teltronic.es

Hello,

I’m using a Linux userspace application with Libmetal to communicate core 0 (Linux) and core 1 (FreeRTOS) in a Zynq 7000. The application is very simple, as it only forwards messages between cores and works very well, but I have noticed that it creates an additional thread automatically. I suspect this is because of Libmetal, as OpenAMP’s wiki states:

“The Linux userspace implementation will use a thread to call select() function to listen to the file descriptors of the devices to see if there is an interrupt triggered. If there is an interrupt triggered, it will call the interrupt handler registered by the user application.”

However, I was planning system priorities to configure the userspace watchdog daemon and noticed that this thread has SCHED_FIFO scheduling policy with a priority of 99 (the highest possible). This priority is above all my userspace applications, including the watchdog daemon, and even above several kernel threads, which worries me.

The code responsible for this behavior is inside libmetal/lib/system/linux/irq.c, function metal_linux_irq_handling(void * args):

param.sched_priority = sched_get_priority_max(SCHED_FIFO);

/* Ignore the set scheduler error */

ret = sched_setscheduler(0, SCHED_FIFO, &param);

My question is: can I lower the priority of this thread? If the answer is yes, what would be the minimum required priority for Libmetal to operate properly?

Thank you very much and best regards,

Eduardo.

Eduardo Viruete

Software Engineer

Teltronic

Tel: +34 976 465656 Ext. 313

[1]www.teltronic.es

References

1. http://www.teltronic.es/