kernel version

[jon]

On Sun, 2013-02-24 at 21:48 +0100, Sascha Herrmann wrote:
> >>> Why the hell the preempt cant be toggled on/off from user space is a
> 
> >>> mystery - its just a timer on an IRQ why cant I simply turn the timer
> >>> off.
> >> You are sure you understand, what preempt is about?
> > 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.
> 
> This is preemptive multitasking, yes. Linux uses preemptive multitasking
> since the beginning, and it can't be disabled. What preemption in
> context of this kernel configuration means, is that even kernel threads
> can be preempted by higher priority tasks. So disabling the preemption
> option would most likely increase your problems.
Ok, thank you for explaining that, me bad !
Thanks for clearing this up for me, I have failed to understand that
'kernel preemption' is a description of something different from
"preemption calling the kernel" which is how I think of non-cooperative
scheduling.

I knew that linux had a hardware timer tick into the scheduler but I
thought it was pretty course, 17ms on the original i386 rings a bell.
(It was my pride and joy) I was told at the time that normally context
switching happened via a kernel calls ending up in the sceduler, I
remember in the early days gcc runtime code sticking explicit calls to
yield() into code at various points or am I just going senile.

On intel in the old days I used to just disable interrupts for brief
periods from user space applications when I wanted short accurate
delays, guess those days are over !  I looked into doing that on the ARM
but the switch to supervisor mode look like more effort than its worth,
I already see that if I hold the machine for anything over a few ms then
the interrupt handlers will start to lose data.

> >> Why do you think,
> >> that preempt harms you application?
> > I am driving LED signs with a user space application.  For some parts of
> > my code I need to generate small accurate amounts of time for a pulse on
> > a GPIO pin.  Most of the time this works well except when an IRQ comes
> > in or even worse preemption allows the kernel to do its scheduler logic
> > during my timing code causes it schedule the process back in late.
> 
> Had no time to read your post on lkml, but maybe a look at man 2
> sched_setscheduler and searching around for process priorities in linux
> would help you. There are some options to set real time priority for
> user space threads, which you would need in addition, as far as I
> understand it. I never played around with it, so I couldn't help you
> with details about this.
I think it already does this.  The jitter is still not trivial but at
least its scheduled at a nice even high rate.  Interestingly whatever
the RT priority does is not 100% perfect as I have observed infrequent
lockups around 100ms long especially when the machine has just booted.

****code from my project
// This makes a huge difference on 3.x kernel and works reasonably well on 2.6 kernel
#include <sched.h>
void set_realtime(void)
{
        struct sched_param sparam;
        sparam.sched_priority = sched_get_priority_max(SCHED_RR);
        //sched_setscheduler(0, SCHED_FIFO, &sparam);
        sched_setscheduler(0, SCHED_RR, &sparam);
}

Looks like this in ps/top
PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                   
2061 root      rt   0  1872 1752 1400 S  27.5  0.4  91:07.13 red_green_board                                  


Thanks,
Jon