On a GNU/Linux machine, if one wants to do \"real-time\"(sub millisecond time critical) tasks, you almost invariably have to go through the lengthy, complex, and problem prone p
The biggest problem is, many systems where real-time tasking is most useful do not have the fundamental hardware requirements to even allow these patches to work, namely a high resolution timer peripheral.
I strongly disagree: The biggest problem is that you might be blocked or pre-empted for an arbitrary amount of time with no warning. It hardly matters if you can sleep with 1us accuracy if you might occasionally go to sleep for 500ms. Realtime computing is about guaranteed worst case times, not precision sleep intervals. If you want to program an I2C EEPROM you could benefit from a high-resolution timer that would let you meet the setup/hold times as closely as possible without wasting any time. An occasional random delay of 500ms wouldn't matter because the EEPROM would just sit there waiting. That's not a realtime application, though. If you are implementing a control loop with a 1us update to drive a servo, that 500ms delay will cause a huge position disruption while the system runs uncontrolled.
You can't do anything in your application to work around the fact that your disk driver may spend hundreds of milliseconds processing IO completions in an interrupt context. The patches that make the driver friendlier to RT apps are what make an RT kernel.