Re: Can I disable RT throttling?

[Bruce Ashfield <bruce.ashfield@windriver.com>]

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