From: Pradyumna Sampath <pradysam@gmail.com>
To: "M. Koehrer" <mathias_koehrer@arcor.de>
Cc: linux-rt-users@vger.kernel.org, rachana.rao@in.abb.com
Subject: Re: [PATCH] mq_timedrecieve timeout accuracy
Date: Wed, 24 Mar 2010 16:46:21 +0100 [thread overview]
Message-ID: <6d09081c1003240846s31fa5917p470f8936a39662f@mail.gmail.com> (raw)
In-Reply-To: <6d09081c1003240703o19ad3dffx20abae9d15e2d0b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
Hi,
On Wed, Mar 24, 2010 at 3:03 PM, Pradyumna Sampath <pradysam@gmail.com> wrote:
> Ok, I just moved the HZ value from 250 to 1000 and the accuracy has
> improved significantly from 5-7 to 1-2 miliseconds. But IMHO, we
> should still change schedule_timeout to schedule_hrtimeout for better
> accuracy on the timeout because in many cases 1-2 miliseconds is just
> not good enough.
Ok, as promised.
Here is a dirty hack that I made which basically resulted in 2 things.
1) My test programs accurace really really improved. The timeout on
the mq_timedrecieve this time around within the tune of 20-30uS.
2) My actual application exploded all over the place, with mq_*
functions complaining of timing out etc etc .. Just a bad messup.
So (1) confirms that sched_hrtimeout could be a good idea. (2)
Confirms that this patch is really terrible and it would be great if
someone could either come up with something that is more robust or I
will be happy to take suggestions on where and how I should make
changes.
regards
/prady
--
http://www.prady.in
[-- Attachment #2: ipc_mqueue_timeout_to_hrtimeout --]
[-- Type: application/octet-stream, Size: 2002 bytes --]
Index: linux-2.6.33.1-rt10/ipc/mqueue.c
===================================================================
--- linux-2.6.33.1-rt10/ipc/mqueue.c (revision 801)
+++ linux-2.6.33.1-rt10/ipc/mqueue.c (working copy)
@@ -428,10 +428,12 @@
* sr: SEND or RECV
*/
static int wq_sleep(struct mqueue_inode_info *info, int sr,
- long timeout, struct ext_wait_queue *ewp)
+ struct timespec timeout, struct ext_wait_queue *ewp)
{
int retval;
signed long time;
+ ktime_t expire = timespec_to_ktime(timeout);
+ //printk("timeout = %ld %ld\n",timeout.tv_sec, timeout.tv_nsec);
wq_add(info, sr, ewp);
@@ -439,7 +441,8 @@
set_current_state(TASK_INTERRUPTIBLE);
spin_unlock(&info->lock);
- time = schedule_timeout(timeout);
+ //time = schedule_timeout(timeout);
+ time = schedule_hrtimeout(&expire,HRTIMER_MODE_REL);
while (ewp->state == STATE_PENDING)
cpu_relax();
@@ -864,6 +867,7 @@
long timeout;
int ret;
+
if (u_abs_timeout) {
if (copy_from_user(&ts, u_abs_timeout,
sizeof(struct timespec)))
@@ -919,7 +923,8 @@
wait.task = current;
wait.msg = (void *) msg_ptr;
wait.state = STATE_NONE;
- ret = wq_sleep(info, SEND, timeout, &wait);
+ //ret = wq_sleep(info, SEND, timeout, &wait);
+ ret = wq_sleep(info, SEND, ts, &wait);
}
if (ret < 0)
free_msg(msg_ptr);
@@ -956,6 +961,7 @@
struct ext_wait_queue wait;
struct timespec ts, *p = NULL;
+
if (u_abs_timeout) {
if (copy_from_user(&ts, u_abs_timeout,
sizeof(struct timespec)))
@@ -966,6 +972,7 @@
audit_mq_sendrecv(mqdes, msg_len, 0, p);
timeout = prepare_timeout(p);
+ //printk("timedrecieve = %ld %ld\n",ts.tv_sec, ts.tv_nsec);
ret = -EBADF;
filp = fget(mqdes);
if (unlikely(!filp))
@@ -999,7 +1006,8 @@
} else {
wait.task = current;
wait.state = STATE_NONE;
- ret = wq_sleep(info, RECV, timeout, &wait);
+ //ret = wq_sleep(info, RECV, timeout, &wait);
+ ret = wq_sleep(info, RECV, ts, &wait);
msg_ptr = wait.msg;
}
} else {
next prev parent reply other threads:[~2010-03-24 15:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-24 12:27 mq_timedrecieve timeout accuracy Pradyumna Sampath
2010-03-24 13:12 ` John Kacur
2010-03-24 13:21 ` Sujit K M
2010-03-24 13:22 ` M. Koehrer
2010-03-24 13:37 ` Pradyumna Sampath
2010-03-24 13:45 ` Sujit K M
2010-03-24 13:47 ` Pradyumna Sampath
2010-03-24 14:03 ` Pradyumna Sampath
2010-03-24 15:46 ` Pradyumna Sampath [this message]
2010-03-29 15:08 ` [PATCH] " Carsten Emde
2010-03-30 7:41 ` Pradyumna Sampath
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=6d09081c1003240846s31fa5917p470f8936a39662f@mail.gmail.com \
--to=pradysam@gmail.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=mathias_koehrer@arcor.de \
--cc=rachana.rao@in.abb.com \
/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).