And another tweak. Having looked at the actual code for usleep_range(),
I'm now basically doing the same (calling schedule_hrtimeout_range()),
although in absolute mode. This makes everything simpler, as I can then
just keep forwarding my original timeout with 10ms, instead of having to
keep track of how long my work took - and it minimizes drift also.
In addition to the below changes, I've also changed to a tickless kernel,
btw.
static int bus_rt_timer_thread(void *arg)
{
struct custombus_device_driver *cbdrv, *next_cbdrv;
printk(KERN_INFO "RT Thread entering loop\n");
ktime_t timeout = ktime_get();
while(!kthread_should_stop()) {
rt_mutex_lock(&list_10ms_mutex);
list_for_each_entry_safe(cbdrv,next_cbdrv,&polling_10ms_list,poll_list) {
driver_for_each_device(&cbdrv->driver, NULL, NULL,
cbdrv->poll_function);
}
rt_mutex_unlock(&list_10ms_mutex);
timeout = ktime_add_us(timeout, 10000);
__set_current_state(TASK_UNINTERRUPTIBLE);
schedule_hrtimeout_range(&timeout, 100, HRTIMER_MODE_ABS);
}
printk(KERN_INFO "RT Thread exited\n");
return 0;
}
int __init bus_timer_interrupt_init(void)
{
struct sched_param param = { .sched_priority = MAX_RT_PRIO - 1 };
thread_10ms = kthread_create(bus_rt_timer_thread, NULL,
"bus_10ms");
if (IS_ERR(thread_10ms)) {
printk(KERN_ERR "RT Failed to create RT thread\n");
return -ESRCH;
}
sched_setscheduler(thread_10ms, SCHED_FIFO, ¶m);
wake_up_process(thread_10ms);
printk(KERN_INFO "RT Timer thread installed with standard priority
%d.\n", param.sched_priority);
return 0;
}
This implementation is again even simpler, and also performs better.
30-minute stress test results:
Old implementation (original hr_timer):
Cycles over 10.3 ms: 3144
Cycles under 9.7 ms: 3852
Max. cycletime: ~56.5 ms
New implementation (usleep_range):
Cycles over 10.3 ms: 26
Cycles under 9.7 ms: 0
Max. cycletime: ~10.4 m
New new implementation (schedule_hrtimeout_range):
Cycles over 10.3 ms: 0
Cycles under 9.7 ms: 0
Max. cycletime: ~10.2 m
Again, comments, questions, anything else is welcome,
Best regards,
Simon Falsig
--
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
