RT PREEMPT patches?

The way _single_ CPU archs that don't have atomic instructions handle Futex (User space Mutex: here interrupt can't be disabled to prohibit a context switch) is to create a "atomic region": a memory page where the would-be atomic instructions sit. On interrupt (-return) the Kernel checks if such an instruction had been interrupted and finishes it before returning after same.

Of course this does not work that easy with multiple CPUs. but here a hardware flag that is set before and reset after the would be atomic instruction by a custom instruction (that other than an I/O access can be executed in user space) could be used to do a spinlock and the interrupt issue might be handled in a similar way as with a single CPU system.

-Michael

Hi,

--- Quote Start ---

Of course this does not work that easy with multiple CPUs. but here a hardware flag that is set before and reset after the would be atomic instruction by a custom instruction (that other than an I/O access can be executed in user space) could be used to do a spinlock and the interrupt issue might be handled in a similar way as with a single CPU system.

--- Quote End ---

I know your idea, but where do you make the hardware flag? The NIOS CPU has 6 pipeline stages Fetch, Decode, Execute, Memory, Align and Write back. Maybe the custom instruction's hardware belongs to the 'Execute' stage, but we don't know which stage accepts the interruptions. So maybe, we can't solve the delicate timing problem between the flag set/reset and interruptions.

Moreover, after applying the CONFIG_PREEMPT_RT patch, it is quite natural that someone will ask 'Does anyone build the kernel with CONFIG_SMP?' . So I think it's better for us to keep the original aspect of kernel sources and put the ungraceful parts into the machine dependent 'MACRO'.

Now I'm seeking another way.

Kazu

--- Quote Start ---

where do you make the hardware flag? The NIOS CPU has 6 pipeline stages Fetch, Decode, Execute, Memory, Align and Write back. Maybe the custom instruction's hardware belongs to the 'Execute' stage, but we don't know which stage accepts the interruptions. So maybe, we can't solve the delicate timing problem between the flag set/reset and interruptions.

--- Quote End ---

Of course, my old idea of using such a custom-instruction managed flag to make interrupts within the atomic region less likely by disabling interrupts accdording to that flag only helps with a single CPU and due to the queue issue you mentioned it only reduces the likelihood of such an interrupt but does not prevent it and the atomic-return code needs to stay in place.

I did not do much thinking about how to do multi-CPU atomic instructions (here interrupt is no issue at all), but a spinlock done with a custom instruction is the only way I can think of.

--- Quote Start ---

Moreover, after applying the CONFIG_PREEMPT_RT patch, it is quite natural that someone will ask 'Does anyone build the kernel with CONFIG_SMP?' . So I think it's better for us to keep the original aspect of kernel sources and put the ungraceful parts into the machine dependent 'MACRO'.

Now I'm seeking another way.

--- Quote End ---

I feel before thinking decently about SMP a fully functional single CPU MMU distribution is necessary. Of course the Realtime Patch wo9uld be really nice to have, but a decently approved distr would be even nicer :rolleyes:

-Michael