Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965443AbbLHPfQ (ORCPT ); Tue, 8 Dec 2015 10:35:16 -0500 Received: from mail-oi0-f52.google.com ([209.85.218.52]:33204 "EHLO mail-oi0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965251AbbLHPfM (ORCPT ); Tue, 8 Dec 2015 10:35:12 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 8 Dec 2015 21:05:11 +0530 Message-ID: Subject: Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ? From: Aniroop Mathur To: Thomas Gleixner , clemens@ladisch.de Cc: John Stultz , a.mathur@samsung.com, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2802 Lines: 66 On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner wrote: > On Tue, 8 Dec 2015, Aniroop Mathur wrote: >> On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner 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/