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

[Aniroop Mathur]

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

On Wed, Dec 9, 2015 at 2:17 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Tue, 8 Dec 2015, Aniroop Mathur wrote:
>> On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/