Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1291473 > unrolled thread

Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Ques: [kernel/time/*] Is there any disadvantage in using  sleep_range for more than 20ms delay ? Aniroop Mathur <aniroop.mathur@gmail.com> - 2015-12-14 20:10 +0100
    Re: Ques: [kernel/time/*] Is there any disadvantage in using  sleep_range for more than 20ms delay ? Thomas Gleixner <tglx@linutronix.de> - 2015-12-14 21:00 +0100
      Re: Ques: [kernel/time/*] Is there any disadvantage in using  sleep_range for more than 20ms delay ? Aniroop Mathur <aniroop.mathur@gmail.com> - 2015-12-21 18:30 +0100

#1291473 — Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ?

On Sun, Dec 13, 2015 at 3:17 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
> Aniroop Mathur wrote:
>>> 1. If we choose usleep_range to acheive accuracy, are cpu and power usage
>>> of any concern in real sense ?
>
> That depends.  The effects are worse if the CPU is sleeping, and slow to
> wake up.
>
> But that's _your_ job to decide.  (And you know your hardware better.)
>

Umm... could you please elaborate it ?

>>> 2. If we use msleep(40), is it possible that process could wake up after
>>> 60 ms or 70 ms or 100 ms or more ?
>
> Yes, if lots of other processes compete for the CPU.
>
>

You mean to say "yes" for process competing for changing state
from "waiting" to "ready" or "ready" to "running" ?

Regarding above, could you please help to confirm below things?
1. Using msleep(40) with HZ=1000 (1ms), process can still be in
"waiting" state and will not move to "ready" state even after 42,45 or 50 ms.
Right ?
2. Using usleep_range(40000, 41000), it is guaranteed that process will
change its state from waiting to ready state before or at 41 ms.
Right ?


Regarding usleep_range disadvatage:
1. Usleep_range has a disadvantage that it does not allow the system to
do optimal timer batching for power savings. Except that, Is there any
other disadvantage ?
2. Is the impact of optimal timer batching in systems like android or ubuntu
with moderate cpu speed significant or it can be negligible also?
To understand the impact better, it would be really appreciating if you could
kindly explain in detail with some case and data input.


Regards,
Aniroop Mathur

> Regards,
> Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1291518

On Tue, 15 Dec 2015, Aniroop Mathur wrote:
> On Sun, Dec 13, 2015 at 3:17 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
> > Aniroop Mathur wrote:
> >>> 2. If we use msleep(40), is it possible that process could wake up after
> >>> 60 ms or 70 ms or 100 ms or more ?
> >
> > Yes, if lots of other processes compete for the CPU.
> 
> You mean to say "yes" for process competing for changing state
> from "waiting" to "ready" or "ready" to "running" ?

There is no state ready. We change from [un]interruptible to running,
but that's just the wakeup by the timer callback. When the task gets
on the CPU is a different question.
 
> Regarding above, could you please help to confirm below things?
> 1. Using msleep(40) with HZ=1000 (1ms), process can still be in
> "waiting" state and will not move to "ready" state even after 42,45 or 50 ms.
> Right ?

kernel/time/timer.c:apply_slack()

> 2. Using usleep_range(40000, 41000), it is guaranteed that process will
> change its state from waiting to ready state before or at 41 ms.
> Right ?

1) It is supposed to be woken up by the timer in that range, but there
   is no guarantee. Depends also on your kernel configuration and
   hardware capabilities.

2) The state changes from [un]interruptible to running. And again
   that does not tell you when it gets on the CPU.

> Regarding usleep_range disadvatage:
> 1. Usleep_range has a disadvantage that it does not allow the system to
> do optimal timer batching for power savings. Except that, Is there any
> other disadvantage?

Higher CPU usage.

> 2. Is the impact of optimal timer batching in systems like android or ubuntu
> with moderate cpu speed significant or it can be negligible also?
> To understand the impact better, it would be really appreciating if you could
> kindly explain in detail with some case and data input.

  http://bfy.tw/3HaV
  http://bfy.tw/3Han
  ....

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296092

On Tue, Dec 15, 2015 at 1:23 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 15 Dec 2015, Aniroop Mathur wrote:
>> On Sun, Dec 13, 2015 at 3:17 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
>> > Aniroop Mathur wrote:
>> >>> 2. If we use msleep(40), is it possible that process could wake up after
>> >>> 60 ms or 70 ms or 100 ms or more ?
>> >
>> > Yes, if lots of other processes compete for the CPU.
>>
>> You mean to say "yes" for process competing for changing state
>> from "waiting" to "ready" or "ready" to "running" ?
>
> There is no state ready. We change from [un]interruptible to running,
> but that's just the wakeup by the timer callback. When the task gets
> on the CPU is a different question.
>
>> Regarding above, could you please help to confirm below things?
>> 1. Using msleep(40) with HZ=1000 (1ms), process can still be in
>> "waiting" state and will not move to "ready" state even after 42,45 or 50 ms.
>> Right ?
>
> kernel/time/timer.c:apply_slack()
>
>> 2. Using usleep_range(40000, 41000), it is guaranteed that process will
>> change its state from waiting to ready state before or at 41 ms.
>> Right ?
>
> 1) It is supposed to be woken up by the timer in that range, but there
>    is no guarantee. Depends also on your kernel configuration and
>    hardware capabilities.
>
> 2) The state changes from [un]interruptible to running. And again
>    that does not tell you when it gets on the CPU.
>
>> Regarding usleep_range disadvatage:
>> 1. Usleep_range has a disadvantage that it does not allow the system to
>> do optimal timer batching for power savings. Except that, Is there any
>> other disadvantage?
>
> Higher CPU usage.
>

Really appreciate your input, Mr. Thomas.
Suddenly today, I thought again and realised than Less Power Saving and
High CPU Usage are disadvantages of usleep_range as a whole and not only
when used for delays more than 20ms.
I hope my understanding is right.
If yes, Could you please help to confirm my above understanding ?
and let me know if there is any disadvantage "specifically for large delays" ?

Thanks again for your support on this.

Regards,
Aniroop Mathur

>> 2. Is the impact of optimal timer batching in systems like android or ubuntu
>> with moderate cpu speed significant or it can be negligible also?
>> To understand the impact better, it would be really appreciating if you could
>> kindly explain in detail with some case and data input.
>
>   http://bfy.tw/3HaV
>   http://bfy.tw/3Han
>   ....
>
> Thanks,
>
>         tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web