lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1512082140060.3595@nanos>
Date:	Tue, 8 Dec 2015 21:47:44 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Aniroop Mathur <aniroop.mathur@...il.com>
cc:	clemens@...isch.de, John Stultz <john.stultz@...aro.org>,
	a.mathur@...sung.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: 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@...utronix.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ