[rtl] "dedicating" processor to RT-task.

[Tomasz Motylewski <motyl@stan.chemie.unibas.ch>]

Some people, including myself, think that it would be cool to run real-time
processes on a dedicated processor in SMP system, with interrupts blocked. 

I have tried to run a program which did:

mlockall(MCL_CURRENT);
iopl(3);
shed_parm.sched_priority=10
sched_setscheduler(0,SCHED_FIFO,&shed_parm);
sync()
few second delay loop;
__asm__(
        "cli"
        );

some loop toggling bits in paralel port -
do it for 10 second;

__asm__(
        "sti"
        );

exit(0);

I hoped that if I will get it to run on a processor 1 (I assume that
processor 0 is getting interrupts in 2.0.33) than the rest of the system will
work (I know the limitations of single kernel lock, but this is user space).

The system was just stoping for that 10 s and I have traced it to:
arch/i386/kernel/smp.c:
switch(wait)
        {
                case 1:
                        while(cpu_callin_map[0]!=target_map);           /*
Spin on the pass             */
                        break;
                case 2:
                        while(smp_invalidate_needed);                   /*
Wait for invalidate map to clear */
                        break;
        }

Now the question:

will bad things happen if I just add a "capability" flag "leave_me_alone" to
cpu_data[n].x86_capability and then do 

if(cpu_data[target].x86_capability & LEAVE_ME_ALONE) return; 

at the beginning of smp_message_pass(...) ? Then I should just set
LEAVE_ME_ALONE flag near cli in my program and I am ready ??? (I know, I will
have to use some syscall to do it. May be additional sched_setscheduler flag 
SCHED_UNINTERRUPTIBLE ?

Unfortunately I am leaving for Easter holiday just now, but I will for sure
try what happens when I return.

And how to block given processor from receiving interrupts in recent 2.1.9x ?

--
Tomasz Motylewski

P.S. I was suprised when I measured the time used by a single byte write
syscall on IBM 6x86MX-PR200 - it was only 2.5 us (simple character device). 


--- [rtl] ---
For more information on Real-Time Linux see:
http://rtlinux.cs.nmt.edu/