AMP on an SMP system
Hi Experts. Is there a kind of official way to set aside one of the available cores in an SMP system from the Linux OS to do deeply embedded extremely-low-latency stuff in a kind of single task main loop type environment ? I.e. creating a true coprocessor from an SMP hardware. Some of the problems that come in ind here include: - how to make the Linux initialization ignore one of the available cores or free a core later on ? Here I found this: http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re46.html So using one of the four cores for special purpose in fact is viable. - how to have a Linux task start the free running main loop ? - how to assign certain interrupts to that core and have ISRs run there only dedicatedly interrupting the main loop and not ever being blocked by any Linux activity ? here I found this: https://access.redhat.com/site/solutions/15482 In fact of course the hardware defines if/how a certain Interrupt can be assigned to a certain CPU. How is this usually done when using ARM Cortex A9+ cores ? - what about MMU issues ? - how to have a Linux application communicate with the non.-Linux application running on the dedicated core ? Here I found this: http://lwn.net/Articles/464391 For example I (e.g.) would like a (now rather cheap) standard quadcore ARM Cortex A9 processor chip and modify a Debian distribution in a way that support this stuff. Thanks for any pointers ? -Michael -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMP on an SMP system
On 08/02/2013 01:42 PM, Robert Schwebel wrote: Before hacking around (which might also lead to interesting solutions), I would start using a kernel with preempt-rt support and play with the cpu affinity: http://lxr.linux.no/#linux+v3.10.4/Documentation/kernel-parameters.txt#L1257 Robert ! Nice to see you here (I do own your Embedded Linux Handbuch für Entwickler :-) ) Thanks for the pointer ! I do already know preempt-rt, but I was not aware of cpu affinity. So this might help. In fact I need a way to do very guaranteed low latency. regarding the high clock rate (about 1 GHz) modern ARM chips can provide, maybe preempt-rt with the cpu affinity might be a decent way to go. The raining questions include - how to calculate the maximum latency that can be guaranteed ? (i.e. does the Kernel impose any spinlocks and interrupt disables on the would be AMP subsystem ?) - how to assign an interrupt (e.g. a dedicated timer) to the subsystem ? - Do the interrupts immediately call the ISR of the cpu under affinity or is some additional latency imposed by the Kernel (and how many cpu cycles at max are needed to enter the ISR) ? Thanks, -Michael -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMP on an SMP system
Il 02/08/2013 14:13, Michael Schnell ha scritto: On 08/02/2013 01:42 PM, Robert Schwebel wrote: Before hacking around (which might also lead to interesting solutions), I would start using a kernel with preempt-rt support and play with the cpu affinity: http://lxr.linux.no/#linux+v3.10.4/Documentation/kernel-parameters.txt#L1257 Robert ! Nice to see you here (I do own your Embedded Linux Handbuch für Entwickler :-) ) Thanks for the pointer ! I do already know preempt-rt, but I was not aware of cpu affinity. So this might help. In fact I need a way to do very guaranteed low latency. regarding the high clock rate (about 1 GHz) modern ARM chips can provide, maybe preempt-rt with the cpu affinity might be a decent way to go. Just to be clear: at the moment there isn't an easy way to dedicate completely a cpu for a task. The last time I tried (some years ago actually) to use exclusive cpu set, the scheduler didn't do a good work because it was designed for SMP, not SMP minus some piece. However you can try and you can report your results. It would be interesting. The raining questions include - how to calculate the maximum latency that can be guaranteed ? (i.e. does the Kernel impose any spinlocks and interrupt disables on the would be AMP subsystem ?) No. You can use full dyn tick for example to disable timer interrupt, but it has got some pros and cons, especially with very low latency requirement. - how to assign an interrupt (e.g. a dedicated timer) to the subsystem ? Interrupt handler are kernel thread, so you can schedule your kernel thread on your normal cpu. - Do the interrupts immediately call the ISR of the cpu under affinity or is some additional latency imposed by the Kernel AFAIC, no latency for cpu under affinity. (and how many cpu cycles at max are needed to enter the ISR) ? It's difficult to answer to this question because the performance depends on your system. From my last statistics I saw that with an rt linux kernel you can stay below 50us for the interrupt latency. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMP on an SMP system
On 08/02/2013 04:53 PM, Marco Stornelli wrote: - how to assign an interrupt (e.g. a dedicated timer) to the subsystem ? Interrupt handler are kernel thread, so you can schedule your kernel thread on your normal cpu. Sorry. I don't understand. The point I'd like to make is, that for really low latency stuff the ISR needs to take place immediately when the hardware fires an interrupt. As the Linux kernel will (for the SMP CPUs it handles) need to disable interrupt in certain cases, it is essential that the really low latency interrupt is assigned to the AMP cpu (that the Kernel will never touch). AFAIC, no latency for cpu under affinity. That would be great but it need the stuff described above. In fact the interrupt would need to be assigned to the AMP cpu by some hardware means (that I don't know anything about yet), and not be forwarded in any way from some other cpu (which is managed by the Kernel) and thus might be in a interrupt disable state at some point in time. (and how many cpu cycles at max are needed to enter the ISR) ? It's difficult to answer to this question because the performance depends on your system. From my last statistics I saw that with an rt linux kernel you can stay below 50us for the interrupt latency. Of course (sorry for unclear language). I tried to ask for a pointer to start developing an algorithm that allows to predict the max latency the system can offer. Here we could try to do these calculations as well with a really dedicated AMP CPU and with a system using preempt-rt and cpu affinity appropriately. to see if a more standard way to do things might be good enough. Thanks for your answers, -Michael -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMP on an SMP system
Il 02/08/2013 17:24, Michael Schnell ha scritto: On 08/02/2013 04:53 PM, Marco Stornelli wrote: - how to assign an interrupt (e.g. a dedicated timer) to the subsystem ? Interrupt handler are kernel thread, so you can schedule your kernel thread on your normal cpu. Sorry. I don't understand. The point I'd like to make is, that for really low latency stuff the ISR needs to take place immediately when the hardware fires an interrupt. As the Linux kernel will (for the SMP CPUs it handles) need to disable interrupt in certain cases, it is essential that the really low latency interrupt is assigned to the AMP cpu (that the Kernel will never touch). AFAIC, no latency for cpu under affinity. That would be great but it need the stuff described above. In fact the interrupt would need to be assigned to the AMP cpu by some hardware means (that I don't know anything about yet), and not be forwarded in any way from some other cpu (which is managed by the Kernel) and thus might be in a interrupt disable state at some point in time. I don't know your hw so my consideration are really general. ISRs in rt kernel doesn't exist or at least the only work is to wake up the kernel thread for the management. The thing you can do is to move the kernel thread for interrupt X where you want to manage it, or you can set a specific scheduler policy. For example you can set a SCHED_FIFO with a very high priority for your really low latency tasks. RT kernel does the work for you :) You can see here: http://lwn.net/Articles/146861/ Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMP on an SMP system
On 08/02/2013 05:37 PM, Marco Stornelli wrote: I don't know your hw so my consideration are really general. The hardware is not decided yet (it will be some A9 thingy). So for me really general is just fine. ISRs in rt kernel doesn't exist or at least the only work is to wake up the kernel thread for the management. I see. But how to determine the max latency for this ? The thing you can do is to move the kernel thread for interrupt X where you want to manage it, or you can set a specific scheduler policy. For example you can set a SCHED_FIFO with a very high priority for your really low latency tasks. RT kernel does the work for you :) You can see here: http://lwn.net/Articles/146861/ This seems be rather easy to do. If this is good enough latency wise, it seems to be the way to go. -Michael -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMP on an SMP system
Il 02/08/2013 18:00, Michael Schnell ha scritto: On 08/02/2013 05:37 PM, Marco Stornelli wrote: I don't know your hw so my consideration are really general. The hardware is not decided yet (it will be some A9 thingy). So for me really general is just fine. ISRs in rt kernel doesn't exist or at least the only work is to wake up the kernel thread for the management. I see. But how to determine the max latency for this ? Maybe on eLinux.org you can find some number. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMP on an SMP system
You might try the Open Source Automation Development Labs website for real-time
Linux latency measurements and methodology:
http://www.osadl.org/
\
Jon
Marco Stornelli marco.storne...@gmail.com wrote:
Il 02/08/2013 18:00, Michael Schnell ha scritto:
On 08/02/2013 05:37 PM, Marco Stornelli wrote:
I don't know your hw so my consideration are really general.
The hardware is not decided yet (it will be some A9 thingy). So for me
really general is just fine.
ISRs in rt kernel doesn't exist or at least the only work is to wake
up the kernel thread for the management.
I see.
But how to determine the max latency for this ?
Maybe on eLinux.org you can find some number.
Marco
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{�zf�uם�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
MESSAGE FROM YONG WONG!
Good Day, I appologize for using this medium of internet to reach you, though it has been greatly abused, but I chose to reach you because it is still the fastest means of communication in the world, however this correspondent is unofficial and private. My name is Yong Wong, I work with the hang seng Bank Hong Kong, I have a business proposition for you involving the sum of $24.500.000.00 Million Dollars in my bank which I know we will be of mutual benefit to both of us,There is no risk involved. If interested please reply back to my private email: wongyong...@yahoo.com.hk Regards, Yong Wong. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
