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
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
On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner <[email protected]> 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
On Tue, 8 Dec 2015, Aniroop Mathur wrote:
> On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner <[email protected]> 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
On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <[email protected]> wrote:
> On Tue, 8 Dec 2015, Aniroop Mathur wrote:
>> On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner <[email protected]> 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
On Tue, 8 Dec 2015, Aniroop Mathur wrote:
> On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <[email protected]> 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
On Dec 9, 2015 2:18 AM, "Thomas Gleixner" <[email protected]> wrote:
>
> On Tue, 8 Dec 2015, Aniroop Mathur wrote:
> > On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <[email protected]> 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 in 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.
In case of booting,
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, 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. And so saving time in initialization part can
save time of 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 incomplete.
Could you please provide the answer to my earlier two queries:
1. If we choose usleep_range to acheive accuracy, are cpu and power usage
of any concern?
2. If we use msleep(40), is it possible that process could wake up at
60 ms or 70 ms or 100 ms or more ?
BR,
Aniroop Mathur
> Thanks,
>
> tglx????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Sorry for multiple emails as those were not in plain text so ignored
by [email protected]
Please consider this email for reply.
On Wed, Dec 9, 2015 at 2:17 AM, Thomas Gleixner <[email protected]> wrote:
> On Tue, 8 Dec 2015, Aniroop Mathur wrote:
>> On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <[email protected]> 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
On Sun, Dec 13, 2015 at 3:17 PM, Clemens Ladisch <[email protected]> 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
On Tue, 15 Dec 2015, Aniroop Mathur wrote:
> On Sun, Dec 13, 2015 at 3:17 PM, Clemens Ladisch <[email protected]> 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
On Tue, Dec 15, 2015 at 1:23 AM, Thomas Gleixner <[email protected]> wrote:
> On Tue, 15 Dec 2015, Aniroop Mathur wrote:
>> On Sun, Dec 13, 2015 at 3:17 PM, Clemens Ladisch <[email protected]> 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