kernel version

[Federico]

Hello everyone,

jon <jon at ...> writes:
> To me (an old bald man who remembers 8088 CPUs) preemption is to enter
> the kernel on a hardware timer interrupt allowing the scheduler to do
> its thing without a process making an explicit kernel call. IE hardware
> timer tick based scheduling rather than co-operative.  I assume (having
> read the docs) that the preempt patch modifies the kernel with some
> extra locks or critical sections and allows a hardware timer to tick to
> drive the scheduler in parallel to the normal yeild mechanism.  Am I
> close ?

PREMPT affects kernel preemption only, in a good way, reducing the jitter on the
latencies due to syscalls.
Linux is not DOS, processes are always preempted, even selecting PREEMPT_NONE at
compile time. I'm not aware of any scheduling algorithm that allows an userspace
process to lock itself in.
Probably a device driver can do that, and only in this case PREEMPT_NONE could
give a real advantage.

If you have such a strict timing for an userspace code you should try some
real-time O.S. Unfortunately the RT_PREEMPT patchset isn't yet applicable to
current rpi kernel (unless something changed recentely).
The good news it that xenomai seems to be working
(http://sourceforge.net/p/rtraspberrylinu/blog/) and its even harder real-time.
In short you run in xenomai the code driving the LEDs and in linux the rest of
your application. This doesn't come at zero cost in terms of time but it should
fit your needs.

Regards

--
Federico