RT PREEMPT patches?

[Altera_Forum]

Has anybody tried applying RT PREEMPT patches (http://rt.wiki.kernel.org/) to Nios II Linux?

[Altera_Forum]

With the non-MMU Linux distribution you can select "preemptive Kernel" in "make menuconfig".,  

 I suppose it's the same with the Full Linux distribution, but I did not try yet.  -Michael

[Altera_Forum]

"Preemptive kernel" option makes critical sections non preemptible, unlike "Real-Time Preemptible Kernel" option of RT patch that does it. 

 Besides, RT patch requires a hardware high resolution timer (ACPI or HPET), lack of high resolution timers restricts real time applications.

[Altera_Forum]

I tried to see how far I can get with this. So far the main problem is that the latest patchset is for Linux 2.6.31 while the unstable-nios2 branch I'm working off of is Linux 2.6.32-rc6 so many of the patches don't apply.

[Altera_Forum]

Hi. 

 Do you use µClinux for NIOS II without MMU or Linux for NIOS II with MMU?  I think the best start is to use Linux for NIOS II with MMU because RT PREEMPT has been done for x86 with MMU first and modifies several Linux files but few files in the arch directory...  For synchronizing the Linux source for NIOS II and the RT PREEMPT patch, you may use a git command for having a new branch of the Linux source for NIOS II that is the nearest as possible of a RT PREEMPT patch version (with a commit id).  git command example: $ git checkout -b preempt d01303a1035a39e445007c7522d89ad985c4153c  List of commit ids for stable branch nios2mmu here http://sopc.et.ntust.edu.tw/?p=linux-2.6.git;a=shortlog  Pat. 

[Altera_Forum]

--- Quote Start ---  Hi.  Do you use µClinux for NIOS II without MMU or Linux for NIOS II with MMU?  I think the best start is to use Linux for NIOS II with MMU because RT PREEMPT has been done for x86 with MMU first and modifies several Linux files but few files in the arch directory...  For synchronizing the Linux source for NIOS II and the RT PREEMPT patch, you may use a git command for having a new branch of the Linux source for NIOS II that is the nearest as possible of a RT PREEMPT patch version (with a commit id).  git command example: $ git checkout -b preempt d01303a1035a39e445007c7522d89ad985c4153c  List of commit ids for stable branch nios2mmu here http://sopc.et.ntust.edu.tw/?p=linux-2.6.git;a=shortlog  Pat.   --- Quote End ---    I used the MMU version, I think that's the only reasonable approach since that's basically regular Linux.  I think checking out a nios2mmu branch/revision matching the Linux version of the RT branch would be a good start, but I would like to keep all the latest nios2 related changes (I am currently on unstable-nios2mmu), and my git-fu is lacking here. How would I get Linux 2.6.31 (or whatever the exact version I need for RT) but get the nios2 specific changes in unstable-nios2mmu? I am also concerned that if I try that I will run into the same types of issues I have with trying to merge 2.6.31-rt directly into unstable-nios2mmu.

[Altera_Forum]

Hi, 

 OK for the MMU version. In the stable version, the Linux version is 2.6.30 (in the Makefile). In the unstable version, the Linux version is 2.6.32-rc6.  You may apply the nearest RT patch to the NIOS Linux version and modify by hand rejected files (in the best case, juste sliding lines...). But you have to modify some arch/nios2 files from scratch for porting RT PREEMPT. Have you read my PM on this point?  Pat.

[Altera_Forum]

Hippo:  

 Will the standard (MMU-based) include selecting the PREEMPT patches out of the box some day ?   I feel that is highly appropriate (if it does work).  -Michael

[Altera_Forum]

Hi, 

 Normal CONFIG_PREEMPT is working fine (of course, I don't know its efficiency). This configuration avoids the critical sections by only disabling the interruptions. For CONFIG_PREEMPT_RT, you need not only to apply the patches but to make Nios's machine dependent codes which are very similar for SMP systems.  Kazu

[Altera_Forum]

--- Quote Start ---  Hi,make Nios's machine dependent codes which are very similar for SMP systems.Kazu  --- Quote End ---   I feel that doing SMP System code for NIOS is a real challenge, as NIOS does not fave atomic instructions. I did some research on how it could be possible to provide a kind of Mutex with custom instructions that could be used to protect instruction sequences to make them atomic. I suppose this is possible and extensible to multiple CPUs, but you do need additional "hardware" to do this and I did not exactly proof that it might work.   Do you think this is needed to apply the CONFIG_PREEMPT_RT patch ?   -Michael

[Altera_Forum]

Hi, 

   --- Quote Start ---  I feel that doing SMP System code for NIOS is a real challenge, as NIOS does not fave atomic instructions. I did some research on how it could be possible to provide a kind of Mutex with custom instructions that could be used to protect instruction sequences to make them atomic. I suppose this is possible and extensible to multiple CPUs, but you do need additional "hardware" to do this and I did not exactly proof that it might work.    --- Quote End ---     Several CPUs make 'Mutex' by using atomic instructions. But both for SMP system and CONFIG_PREEMPT_RT, we only need the 'Mutex' mechanism, not atomic instructions. And I don't think that we can make 'Mutex' by using custom instructions because there is no information about interrupt acception timing, pipeline behaviors and custom instructions.    --- Quote Start ---   Do you think this is needed to apply the CONFIG_PREEMPT_RT patch ?    --- Quote End ---    We must enable the interruption in the critical section, so we need some kind of 'Mutex'.  Kazu

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

--- 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