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

Groups > linux.kernel > #1285829 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  Ques: [kernel/time/*] Is there any disadvantage in using sleep_range  for more than 20ms delay ? Aniroop Mathur <aniroop.mathur@gmail.com> - 2015-12-07 19:00 +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-07 19:40 +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-08 03:50 +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-08 11:50 +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-08 16:40 +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-08 21:50 +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-09 17:20 +0100

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

Dear Mr. John and Mr. Thomas,
Greetings of the day !!

This is Aniroop Mathur working on sensor kernel drivers for last 3 years.
Recently, In my driver code, I have been changing msleep to usleep_range.
But I got stuck at one point and could not find proper answer on internet.
Could you please help to answer my query as mentioned below ?

From the kernel documentation, I understood that it is better to use
usleep_range
for 10 us - 20 ms delay. For delays 10ms+, it is mentioned to use msleep.

If my understanding is right and considering HZ=100,
Even for 33 ms delay, msleep would sleep for 40 ms, while usleep_range
would sleep for 33 ms as desired.
And for 40 ms delay, msleep and usleep_range both will wake up at desired time.
Right ?

As in the kernel documentation, it is mentioned to use msleep for
10ms+ delay, I am confused whether there would be any disadvantage in
using usleep_range for higher delays values because normally drivers
have variety of delays used (2, 10, 20, 40, 100, 500 ms).

So, could you please help to confirm if there could be some problem in
using usleep_range for higher delay values ?

Thanks in advance !

Regards,
Aniroop Mathur
--
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]

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

On Mon, 7 Dec 2015, Aniroop Mathur wrote:
> As in the kernel documentation, it is mentioned to use msleep for
> 10ms+ delay, I am confused whether there would be any disadvantage in
> using usleep_range for higher delays values because normally drivers
> have variety of delays used (2, 10, 20, 40, 100, 500 ms).

The real question is how precise must your delay be? If the delay
needs to be precise within the min/max sleep time limits, then
usleep_range() is probably the way to go. If the delay can be
imprecise then using msleep() is the right way because that lets the
kernel batch timers for power saving purposes.

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]

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

On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 7 Dec 2015, Aniroop Mathur wrote:
>> As in the kernel documentation, it is mentioned to use msleep for
>> 10ms+ delay, I am confused whether there would be any disadvantage in
>> using usleep_range for higher delays values because normally drivers
>> have variety of delays used (2, 10, 20, 40, 100, 500 ms).
>
> The real question is how precise must your delay be? If the delay
> needs to be precise within the min/max sleep time limits, then
> usleep_range() is probably the way to go. If the delay can be
> imprecise then using msleep() is the right way because that lets the
> kernel batch timers for power saving purposes.
>

Thank you for the answer !
Normally, we insert delays in driver while enabling the chip.
So here usleep_range seems to service better as we do not want to delay
the initialisation process of chip and make it ready to generate data,
especially for faster devices like sensor.

One last thing,
Considering HZ=100, would the power saving be same if we set the
range in usleep_range equivalent to msleep ?
For example: msleep (33) and usleep_range(33000, 40000)
So for such case, would both have same impact on power saving ?

Best Regards,
Aniroop Mathur


> 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]

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

On Tue, 8 Dec 2015, Aniroop Mathur wrote:
> On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > The real question is how precise must your delay be? If the delay
> > needs to be precise within the min/max sleep time limits, then
> > usleep_range() is probably the way to go. If the delay can be
> > imprecise then using msleep() is the right way because that lets the
> > kernel batch timers for power saving purposes.
>
> Thank you for the answer !
> Normally, we insert delays in driver while enabling the chip.
> So here usleep_range seems to service better as we do not want to delay
> the initialisation process of chip and make it ready to generate data,
> especially for faster devices like sensor.

The initialization process is hardly something critical, so why would
the delay need to be precise? What's the point of having data 10ms
earlier?
 
> One last thing,
> Considering HZ=100, would the power saving be same if we set the
> range in usleep_range equivalent to msleep ?
> For example: msleep (33) and usleep_range(33000, 40000)
> So for such case, would both have same impact on power saving ?

Probably, but what's the point of doing that?

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]

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

On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 8 Dec 2015, Aniroop Mathur wrote:
>> On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > The real question is how precise must your delay be? If the delay
>> > needs to be precise within the min/max sleep time limits, then
>> > usleep_range() is probably the way to go. If the delay can be
>> > imprecise then using msleep() is the right way because that lets the
>> > kernel batch timers for power saving purposes.
>>
>> Thank you for the answer !
>> Normally, we insert delays in driver while enabling the chip.
>> So here usleep_range seems to service better as we do not want to delay
>> the initialisation process of chip and make it ready to generate data,
>> especially for faster devices like sensor.
>
> The initialization process is hardly something critical, so why would
> the delay need to be precise? What's the point of having data 10ms
> earlier?
>

As I know, the chip initialisation process is critical.
Consider the case for an android mobile phone. When the phone is resumed
from suspend state, all the earlier enabled devices need to be re-initialised.
Normally, we have two sleeps during device initialisation and we need to
re-initialize more than 25 devices on board. So if single msleep
delays by 10 ms,
then the android phone resume is delayed by 10*2*25 = 500 ms, which
is quite a big time.
Also more importantly, during booting the phone as well, if every device sleeps
for extra 20 ms and we have to probe 25 devices, booting is delayed by 500 ms.

So, for above cases, would the power and cpu usage really significant ?
Will it affect any factor noticeably if we use usleep_range ?

>> One last thing,
>> Considering HZ=100, would the power saving be same if we set the
>> range in usleep_range equivalent to msleep ?
>> For example: msleep (33) and usleep_range(33000, 40000)
>> So for such case, would both have same impact on power saving ?
>
> Probably, but what's the point of doing that?
>

My point is to use single consistent sleep api in driver code instead of two
as we need to use it many places in a single driver code. This way, the code
looks better.

Secondly, I know that usleep_range will definitely wake the process
after max time.
But what about msleep ? If we use msleep(40), is it guaranteed that
process will
wake definitely after 50 ms or is it also possible that process can
wake after 60
or 70 or even 100 ms or more ? (HZ=100)

Best Regards,
Aniroop Mathur

> 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]

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

On Tue, 8 Dec 2015, Aniroop Mathur wrote:
> On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > The initialization process is hardly something critical, so why would
> > the delay need to be precise? What's the point of having data 10ms
> > earlier?
> 
> As I know, the chip initialisation process is critical.
> Consider the case for an android mobile phone. When the phone is
> resumed from suspend state, all the earlier enabled devices need to
> be re-initialised.  Normally, we have two sleeps during device
> initialisation and we need to re-initialize more than 25 devices on
> board. So if single msleep delays by 10 ms, then the android phone
> resume is delayed by 10*2*25 = 500 ms, which is quite a big time.
>
> Also more importantly, during booting the phone as well, if every
> device sleeps for extra 20 ms and we have to probe 25 devices,
> booting is delayed by 500 ms.

You are optimizing for something which is simply stupid. WHY do you
need to (re)initialize all devices before you can do something useful?

Just because Android is implemented that way? That's silly.

If you really care about boot time / user experience you initialize
only the really important drivers in the boot/resume process and
initialize the reset in the background. It does not matter whether the
temperatur app shows the updated value one second later or not, but it
matters for the user that the GUI is functional.
 
> My point is to use single consistent sleep api in driver code
> instead of two as we need to use it many places in a single driver
> code. This way, the code looks better.

It's not about better. It's about using the right interfaces for the
right job. usleep_range() and msleep() use different facilities. As I
explained before: If you need a precise limit, use usleep_range(). If
not use msleep().
 
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]

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

Sorry for multiple emails as those were not in plain text so ignored
by linux-kernel@vger.kernel.org
Please consider this email for reply.

On Wed, Dec 9, 2015 at 2:17 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 8 Dec 2015, Aniroop Mathur wrote:
>> On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > The initialization process is hardly something critical, so why would
>> > the delay need to be precise? What's the point of having data 10ms
>> > earlier?
>>
>> As I know, the chip initialisation process is critical.
>> Consider the case for an android mobile phone. When the phone is
>> resumed from suspend state, all the earlier enabled devices need to
>> be re-initialised.  Normally, we have two sleeps during device
>> initialisation and we need to re-initialize more than 25 devices on
>> board. So if single msleep delays by 10 ms, then the android phone
>> resume is delayed by 10*2*25 = 500 ms, which is quite a big time.
>>
>> Also more importantly, during booting the phone as well, if every
>> device sleeps for extra 20 ms and we have to probe 25 devices,
>> booting is delayed by 500 ms.
>
> You are optimizing for something which is simply stupid. WHY do you
> need to (re)initialize all devices before you can do something useful?
>
> Just because Android is implemented that way? That's silly.
>
> If you really care about boot time / user experience you initialize
> only the really important drivers in the boot/resume process and
> initialize the reset in the background. It does not matter whether the
> temperatur app shows the updated value one second later or not, but it
> matters for the user that the GUI is functional.
>

In case of android suspend,
first lcd and touch turns off, then system devices are turned off.
The same process I found in laptop as well. I could see clearly, first lcd went
off and then wifi light was off, bluetooth light was off, mouse light was off.
In resume, reverse process is followed in both. So LCD is turned on at last.
In my opinion, this makes sense as we do not want user to use the gui
or perform any operation untill the system is ready to operate. So with
this sequence we are able to save good time using usleep_range.

In case of booting,
as almost all devices are embedded in the android phone, so probe is called
during booting. In every probe, I have seen the prevention code of checking
chipID or some other prevention code. For this, chip is powered on and
initialized, next i2c operation is performed to read slave address. If slave
address does not match or i2c operation fails, then probe fails and chip is
de-initialized. Also, if probe success, chip is de-initialized. So basically in
probe, chip is always initialized and de-initialized finally. And in
initialization
part,  we need to add delays. So saving time in initialization part can
save good time in booting till home screen.

>> My point is to use single consistent sleep api in driver code
>> instead of two as we need to use it many places in a single driver
>> code. This way, the code looks better.
>
> It's not about better. It's about using the right interfaces for the
> right job. usleep_range() and msleep() use different facilities. As I
> explained before: If you need a precise limit, use usleep_range(). If
> not use msleep().
>

Sure. I understand this part.
However, my main concern is still not resolved clearly.
Could you please update the answer to my earlier two queries:
1. If we choose usleep_range to acheive accuracy, are cpu and power usage
of any concern in real sense ?
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 ?

BR,
Aniroop Mathur

> 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