Re: [Adeos-main] Re: Interrupt Latency Question

[Paolo Mantegazza <mantegazza@domain.hid>]

Max Krasnyansky wrote:
> Hi Paolo,
> 
>> If you have a multicpus machine and can reserve CPUs to real time only,
>> than the picture will change a lot. No Linux activity on them, just your
>> real time programs and irq handlers, likely stuck and fully cached to 
>> those CPUs.
>>
>> This is the solution you'll see native in Linux soon. With true 
>> lowcost multicpus on a single chip massively available within a short 
>> time at the kids' game and mama's word processors store it will change 
>> the whole picture.
> 
> 
> Actually this is kind of available right now with vanilla 2.6 kernel.
> I'm talking about CPU reservation. Here is an example.
> Let's say we have dual CPU box and we want to dedicate CPU 1 to
> our application:
> - Configure the kernel with following boot options:
>     isolcpus=1 acpi_irq_nobalance noirqbalance
> 
>   This excludes CPU 1 from the scheduler balancing logic. And disables
>   ACPI and SW irq balancing.
>   Make sure that you don't run user-space IRQ balancer.
> 
> - Redirect all interrupts to CPU 0
>   for i in /proc/irq/*; do
>     echo 1 > $i/smp_affinity;
>   done
> 
> - Your app call now migrate to CPU 1
>   int cpu = 1;
>   uint32_t mask = (1 << cpu);
>   sched_setaffinity(0, sizeof(mask), (cpu_set_t *) &mask);
> 
> That's it. CPU 1 is yours. There will be almost zero activity on it, 
> besides
> your task of course.
> 

Well such a scheme has been available in RTAI even when it was not 
general in Linux yet (forcing interruts to a CPU dates back to 2.2.x).

For real time CPU reservation I mean something that estabilshes it as 
such directly at boot and are real time applications that have 
specifically to use it, the rest is excluded from the very beginning

Paolo.