On 13-03-11 2:13 PM, David Mulder wrote:
Will that work on a core that's offline?
Nope. Only with an online core controlled by the Linux scheduler.
If you do end up trying to get AMP working, you need to plumbing
to load the other OS/kernel in a reserved memory location, set the
program counter and start the OS.
But that secondary OS has to know how to behave in a system that
it doesn't control, and you'll need ways to communicate with it
from Linux.
remoteproc/rpmsg can solve some of the issues that I mention, but
it is far from out of the box.
That's why there's more interest in running a single task with
exclusive CPU in userspace. The work and scaffolding required to
get an AMP system up and running is non trivial.
I kinda thought so, but I was hopeful.
After speaking with some co-workers, I have a new perspective on these delays:
yes, we are trying to do a 10us control loop, but if we miss a step or two
occasionally we can accept that. And looking online I see people indicating
context switch times well below 10us (Core-i cpus), which is better than I had
anticipated, and should be workable. So I'm going to approach this problem by
just trying to squeeze the kernel as much as I can. Some things that I see to
squeeze are /dev/cpu_dma_latency (should be 0) or max_cstate (should be as low
as possible (0, maybe 1)), possibly idle=poll. Are there other kernel
parameters that can minimize kernel interference/time? And perhaps hints about
how to set them in Yocto or menuconfig?
There's nothing "out of the box" that I can recommend, outside of saying
"it depends on your platform". It's a matter of knowing your devices,
their interrupts, and the configuration of your kernel. Using things
like CONFIG_NOHZ will remove the timer tick, and hence ticks that you
may not need, you want to move device interrupts off your core, except
for the one that you want. Use cgroups/cpusets to control resources and
the scheduler off your core with "other" tasks. pin/lock memory to
avoid page faults, etc.
If you check out the preempt-rt wiki page on kernel.org, a lot of the
information there applies to making sure that your prioritized thread
gets the most run time that it can.
As we progress with the meta-realtime layer, scripts for the above,
system configuration, services and will be part of the layer and might
be of use.
Cheers,
Bruce
Thanks!
Dave
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
