how to use wait_event_interruptible_timeout with less than 1 jiffie timeout?
Hi everybody, I have some code that convert an timeout comming from userspace (in ms) to jiffies prior passing to wait_event_interrupitible_timeout(). The code looks like this: unsigned long tout = user.timeout * HZ / 1000; /* convert from ms to jiffie */ int status = wait_event_interruptible_timeout(wq, cond, tout); I'm using HZ=100, the known default. The problem is: with HZ = 100 and user.timeout = 10 I have: 10 * 100 / 1000 = 1, This means that I can't use timeouts with less than 10ms. Is there any way to circunvent this without changing HZ value? Now let me explain why. I have a protocol running on linux that talk to other embedded systems in an master-slave way. This communication goes through some RF hardware. The communication is maded by master transmitting a frame and receiving another frame from slave. The slave takes about 2 ms to reply, but if the transmitting failed (because the slave was not listening or because the frame was corrupted while traveling through the air) the server has to transmit it again. Today I'm using 10ms as timeout because is the smaller amount that I known how to use, but if I can decrease this timeout to 2 or 3ms I would have a better performance in case of failures. Best regards, -- "Do or do not. There is no try" Yoda Master
[2016-01-20T01:21:18+0530]: "Daniel." (Daniel): ,----[ Daniel ] | I have some code that convert an timeout comming from userspace (in | ms) to jiffies prior passing to wait_event_interrupitible_timeout(). | The code looks like this: | | unsigned long tout = user.timeout * HZ / 1000; /* convert from ms to jiffie */ | int status = wait_event_interruptible_timeout(wq, cond, tout); | | I'm using HZ=100, the known default. | The problem is: with HZ = 100 and user.timeout = 10 I have: | 10 * 100 / 1000 = 1, | | This means that I can't use timeouts with less than 10ms. Is there any | way to circunvent this without changing HZ value? `---- wouldn't msleep_interruptible(...) be a better choice ? as a bonus, it takes care of jiffies wrapping etc.
-- kind regards anupam
On Wed, Jan 20, 2016 at 11:50:24AM +0530, Anupam Kapoor wrote:
[2016-01-20T01:21:18+0530]: "Daniel." (Daniel): ,----[ Daniel ] | I have some code that convert an timeout comming from userspace (in | ms) to jiffies prior passing to wait_event_interrupitible_timeout(). | The code looks like this: | | unsigned long tout = user.timeout * HZ / 1000; /* convert from ms to jiffie */
that should be a unsigned long tout = msecs_to_jiffies(user.timeout); to ensure that all corner cases are properly handled, e.g. for HZ=100 the above would be 0 for user.timeout < 10 which is probably not what you want.
| int status = wait_event_interruptible_timeout(wq, cond, tout); | | I'm using HZ=100, the known default. | The problem is: with HZ = 100 and user.timeout = 10 I have: | 10 * 100 / 1000 = 1, | | This means that I can't use timeouts with less than 10ms. Is there any | way to circunvent this without changing HZ value? `---- wouldn't msleep_interruptible(...) be a better choice ? as a bonus, it takes care of jiffies wrapping etc.
that would still have the same limitation with resepct to time granuarlity and as Documentation/timers/ if you really need very short delays then you will need to resort to hrtimers (and thus be to some extent config dependent) usleep_range(min, max) is the prefered interface in that case. thx! hofrat
[2016-01-20T13:55:54+0530]: "Nicholas Mc Guire" (Nicholas): ,----[ Nicholas ] | that would still have the same limitation with resepct to time granuarlity | and as Documentation/timers/ `---- ah yes, that's true.
,----[ Nicholas ] | if you really need very short delays then you will need to resort to hrtimers | (and thus be to some extent config dependent) usleep_range(min, max) is the | prefered interface in that case. `---- any specific reason why schedule_hrtimeout(...) cannot be used ? -- kind regards anupam
On Wed, Jan 20, 2016 at 06:57:27PM +0530, Anupam Kapoor wrote:
[2016-01-20T13:55:54+0530]: "Nicholas Mc Guire" (Nicholas): ,----[ Nicholas ] | that would still have the same limitation with resepct to time granuarlity | and as Documentation/timers/ `---- ah yes, that's true.
,----[ Nicholas ] | if you really need very short delays then you will need to resort to hrtimers | (and thus be to some extent config dependent) usleep_range(min, max) is the | prefered interface in that case. `---- any specific reason why schedule_hrtimeout(...) cannot be used ?
It can, but same thing, unless you really need a very specific timeout it is better to pass a range so that the kernel can consolidate the timeout list - so the _range is a system level optimization. so schedule_hrtimeout_range() would be prefered <snip> * The @delta argument gives the kernel the freedom to schedule the * actual wakeup to a time that is both power and performance friendly. * The kernel give the normal best effort behavior for "@expires+@delta", * but may decide to fire the timer earlier, but no earlier than @expires. <snip> and you need to convert the timeout to ktime e.g. with ms_to_ktime() thx! hofrat
participants (3)
-
Anupam Kapoor -
Daniel. -
Nicholas Mc Guire