From: Simon Falsig <simon@newtec.dk>
To: linux-rt-users@vger.kernel.org
Subject: RE: Real-time kernel thread performance and optimization
Date: Wed, 12 Dec 2012 16:39:01 +0100 [thread overview]
Message-ID: <ce2a2c5c91e1f62aee4e59c3458ee697@mail.gmail.com> (raw)
In-Reply-To: d27143389b68c615c242b56c7cd4dd22@mail.gmail.com
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
next prev parent reply other threads:[~2012-12-12 15:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 15:46 Real-time kernel thread performance and optimization Simon Falsig
2012-11-30 22:31 ` Frank Rowand
2012-12-03 12:39 ` Simon Falsig
2012-12-03 14:15 ` Carsten Emde
2012-12-11 14:43 ` Simon Falsig
2012-12-19 8:10 ` Carsten Emde
2012-12-20 8:09 ` Simon Falsig
2012-12-19 14:59 ` John Kacur
2012-12-19 15:20 ` Carsten Emde
2012-12-11 14:30 ` Simon Falsig
2012-12-17 22:18 ` Frank Rowand
2012-12-20 0:11 ` Darren Hart
2012-12-20 8:21 ` Simon Falsig
2013-01-02 17:21 ` Darren Hart
2012-12-12 15:39 ` Simon Falsig [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-07-11 6:32 Simon Falsig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ce2a2c5c91e1f62aee4e59c3458ee697@mail.gmail.com \
--to=simon@newtec.dk \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).