Hi,
2011/8/8 Tim Sander <tim.sander@xxxxxxx>:
> Hi
>
> I am currently evaluating the RT Kernel. We are running a interrupt with
> 9.6khz on an arm1136jfs (pcm043) with 533Mhz. When using an softirq
> we are missing interrupts since the scheduler fails to schedule the softirq in
> time :-(.
>
> So i implemented an hardiq which then schedules an tasklet and then triggers
> usermode with an adjustable wakeup divider. The solution with the tasklet
> seems to be even slower than the softirqs from the kernel and the load makes
> the system so slow that it's a pain working on it.
Not surprised ;-)
> So my question is: is there a more efficient way than a tasklet?
Waking up the thread directly from the hardirq could be an option.
Globally you can declare:
struct task_struct *wake_me_up;
In the thread, you can do this:
1. set_current_state(TASK_INTERRUPTIBLE);
2. wake_me_up = current;
3. schedule();
4. wake_me_up = NULL;
In the hardirq you can do something like:
if (wake_me_up)
wake_up_process(wake_me_up);
Of course with the proper locking where needed. (Just meant as pseudo
code, lots of examples can be found in the kernel.
> When comparing the 3.0 vs 3.0-rt7 i can make the general observations:
> * the load seems to be at least twice as high.
> * usermode seems to be scheduled at 2.4khz which is nice.
> * the softirq looses some interrupts at a rate of 9.6khz.
9.6 kHz sounds a lot.
This means about every 100usec an interrupt, the interrupt handler
takes some time and scheduling as well. (I have seen that it can take
up to 50usec to handle an interrupt on some cores.), schedule a thread
and even do some work in userspace...
You should measure (scope or ETM) what time it takes to wake up a
thread from hardirq context on your core.
Kind regards,
Remy
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
